Arma Dialog Editor Preview

[ColonelSandersLite 0]

I've talked to some several of the people here about writing an external dialog editor geared up for ARMA. I thought I'd share what I've done so far.

A lot of interface work, some custom controls, various classes to enable the various bits to communicate with each other, etc. It's not really usable yet, and very much a wip.

Feedback on the way it's going is welcome. Particularly stuff relating to how the interface fundamentally works. Bug reports are not welcome at this early of a stage. Please keep in mind that it's nowhere near finished when making comments.

The Red, White, and Blue squares represent arma dialog interface elements. In fact, these are their unfinished base classes at work. You can select one by clicking on it. You can select multiple objects by shift or control clicking on them. You can deselect a current object by control clicking on it. You can deselect all objects by clicking on the backdrop.

You can edit the properties of the objects and they remember their properties correctly when you unselect them and reselect them. You can select an object from the drop down menu in the properties panel.

You can drag a selected object to a new location by selecting it, clicking on it, holding the mouse button, and dragging it around. You can resize an object by selecting it and clicking and dragging one of the boxes that appear at the edges of the control. You can move and resize multiple objects at the same time if more than one is currently selected.

Note that I can't give support on actually getting this to run. It requires the .net platform to be installed. It should run fine on windows xp, will probably run ok on win2000, will probably not work at all on windows 9x family (win98 and winME), and I have no clue about vista...

Anyways, here's a download link curteosy of armaholic for anyone interested in trying it out .

ColonelSandersLite.armaholic.net/misc/CSL_ARMA_DIALOG_EDITOR_WipDemo2.rar

[ColonelSandersLite 0]

Thanks to feedback from foxhound, some interface elements have been modified some. They are not present in the current available build, so this screen shot will have to suffice .

Full Size

[fasad 1]

G'day CSL,

Nice work, unfortunately I can't test it ATM... A couple of features I'd like to suggest would be :

- Option to show "reserved space" used by the default UI, eg radio log, ammo bar, compass thingo, action menu, command menu etc. I'm not sure how this would works with novel resolutions eg 16:9.

- Grid allowing user defined size (maybe fractions?)

[ColonelSandersLite 0]

I was planning on selectable backgrounds to let you see how your dialog performs in various situations. That takes care of idea 1.

I'm intending on implementing some kind of grid system with snap to grid type functionality, although I haven't gotten around to implementing it in any way shape or form yet.

As far as differing screen reses go, arma is percentage based. So if you specify that a control's x is 0.25, and width is 0.5, it will take up half the screen width with 25% of the screen width on either side.

Since my editor will strive to imitate arma's behaviours as closely as possible, it will work the same before the day is done. It will also have a full screen edit mode which will let you see the way it behaves full size.

[sickboy 13]

Very Very nice CSL! Will be watching this topic like a hawk

[fasad 1]

As far as differing screen reses go, arma is percentage based. So if you specify that a control's x is 0.25, and width is 0.5, it will take up half the screen width with 25% of the screen width on either side.

I was wondering how ArmA draws dialogs in widescreen mode. Will they appear exactly the same as they would in 4:3? If it just uses a % of the total screen pixels, the aspect ratio of the dialog will be distorted if displayed in an aspect ratio other than the one it was designed in. I can't test, I have no video card ATM

I seem to remember seeing screenshots of ArmA in widescreen, showing the HUD appearing only within the center 4:3 section. Hopefully dialogs are treated in the same manner.

[ColonelSandersLite 0]

If that's the case, then I assume they are only registered in the 4:3 section. The HUD elements are just dialog elements, like any other. I've modded them myself (see my UI mod), so I do know what I'm talking about there.

It'll just take a little empirical testing to find out for sure though. All you've got to do is play with the various controls to change the way the game is rendered.

I'm not too worried about it at this stage though.

[t_d 47]

Well this percentage values seems just to work for 4:3 ratio. Have this problem atm and i will ask BIS if this is a bug or by design. Hope it is just a fixable bug.

[ColonelSandersLite 0]

I think you're overlooking something there T_D. I just loaded up my particle parameter utility and it scales just like the rest of the built in interface stuff on different aspect ratios. Here's a screen shot of what happens when you set my regular 4:3 monitor to the tripplehead setting.

Full Size

This is with 1.08.

Take a look at the dialogs in my particle parameter utility and you'll probably be able to figure out what's been missed. Probably some obscure new arma setting.

[t_d 47]

You wont see the bug if you use a small dialog in the middle of the screen. Try this:

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

class FullScreenBG : RscText

{

x = 0.0;

y = 0.0;

w = 1;

h = 1;

text = "";

colorBackground[] = {0, 0, 0, 0.5};

};

Then you will see that x = y = 0 is not on the upper left corner and that the background is not completely filled (if the screen ratio is not 4:3) although w and h is 1

[ColonelSandersLite 0]

Oh, I see what you're saying now. I think that's most definatly not a bug, but a design decision.

If the percentiles changed depending on the screen aspect ration selected, things would look terrible for anybody using a dialog that's not designed for the specific screen ratio you're using.

Basically, if you designed your dialog with a 4:3 ratio in mind, in any higher ratio, it would be all stretched out and stuff. If you designed your stuff in triplehead ratio, it would be all scrunched up for any user using 4:3 ratio.

Like it is now, a dialog will look the same for every user regardless of their resolution and screen ratio, provided the ratio set in the options panel is the correct one for their monitor.

The only problem with that decision is that if a modder is explicitly wanting your dialog to totally fill the screen, you can't do it for any ratio other than 4:3. Well, you *may* be able to set negative values and values over 100 to do it anyways, but that screws anybody using a lesser ratio.

So, the percentile values should only be viewed as percent of the "normal" screen area (4:3) and not percent of the whole screen.

[t_d 47]

Nevertheless, the problem is reported to BIS and I will see what they say.

[Lolsav 0]

Oppps only saw it today. Dling !!!!

[ColonelSandersLite 0]

Oppps only saw it today. Dling !!!!

Heh, I just remembered that you're the dude that sent me down this road in the first place.

[Mr-Murray 0]

Great work Colonel!!!

I look forward to this and hope it´s easy to handle

Regards,

Mr-Murray

[Lolsav 0]

Guilty on "pushing" you down the road... hope it didnt hurt you too badly :P

Reporting: Clearly at early stage, but yes, was some sort of a tool like this i was searching for. The abbility to drag stuff around is nice.

Now... needs a alpha/beta 00.1 version so we can load/save some stuff and try it on editor

Eagerly waiting for next release

[ColonelSandersLite 0]

Guilty on "pushing" you down the road... hope it didnt hurt you too badly :P

Reporting: Clearly at early stage, but yes, was some sort of a tool like this i was searching for. The abbility to drag stuff around is nice.

Now... needs a alpha/beta 00.1 version so we can load/save some stuff and try it on editor

Eagerly waiting for next release

Well, ATM, I've got 477 control parameters and 30 control types I need to very carefully examine before I can continue. I must test each parameter on every control type to find out their exact behaviors ands such. That's 14310 combinations. Then, I need to come up with a full list of what parameters are required, what parameters are optional, and what parameters are disallowed for each of those 30 control types.

On the up side:

Some of them seem to be duplicates. Things like w and width are really the same thing for example.

I'm also sure that some of them are unusable for the end user, as they are designed to tie into the underlying game engine in some way. A good example of this is the emptyMag parameter. That's 90% likely to be only callable by the game engine when the player's magazine is empty, which makes it totally worthless for any dialog designer outside of BIS.

Another added benefit is that when I have all this info, the manual will practically write itself.

A couple of those control types are also going to be beyond the scope of my utility. I have no intention of working with p3d files so the 80 series of controls (object, etc) will be left out, for example.

So, yes, it does hurt. Still, this project is something that needs to be done for the community, so that's all right.

I'm a long ways off from producing something that's actually practically usable in some fashion, but I'm working on it.

For anyone interested, here's a complete list of the various parameters control objects are capable of using.

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

List of ARMA Control Parameters Without Values

477 items

ColorBackground[]

ColorText[]

IDC

OnButtonClick

OnLoad

ShowCountourInterval

SizeEx

Style

access

action

active

aim

align

angle0

angle1

animPeriod

arrowEmpty

arrowFull

arrowHeight

arrowWidth

attack

autocomplete

axis

background

badScoreImage

blinkingPeriod

bloodTexture

border

borderSize

boxHorz

boxLeft

boxRight

cameraScript

canDrag

civl

civlLocked

civlUnlocked

coefMax

coefMin

color0[]

color1[]

color2[]

color

colorAI[]

colorActive[]

colorArrow[]

colorAssigned[]

colorBackgroundActive[]

colorBackgroundCommand[]

colorBackgroundDisabled[]

colorBackgroundHelp[]

colorBackgroundSelected[]

colorBackground[]

colorBar[]

colorBold[]

colorBorder[]

colorCamera[]

colorChecked[]

colorConfirmed[]

colorCountlinesWater[]

colorCountlines[]

colorDirectChannel[]

colorDisable[]

colorDisabled[]

colorEditor[]

colorEnabled[]

colorFocused[]

colorForestBorder[]

colorForest[]

colorFrame[]

colorGlobalChannel[]

colorGroupChannel[]

colorHoldFire[]

colorIDPlayer[]

colorInactive[]

colorLevels[]

colorLinkActive[]

colorLink[]

colorMainCountlinesWater[]

colorMainCountlines[]

colorMainRoadsFill[]

colorMainRoads[]

colorMissionEditor[]

colorMissionWizard[]

colorMission[]

colorNames[]

colorNobody[]

colorNotAssigned[]

colorOpenFire[]

colorPictureBorder[]

colorPictureLink[]

colorPictureSelected[]

colorPicture[]

colorPingBad[]

colorPingGood[]

colorPingPoor[]

colorPingUnknown[]

colorPlayerSelected[]

colorPlayer[]

colorPowerLines[]

colorPrepare[]

colorReady[]

colorRoadsFill[]

colorRoads[]

colorRocksBorder[]

colorRocks[]

colorScrollbar[]

colorSea[]

colorSelect2[]

colorSelectBackground2[]

colorSelectBackground[]

colorSelect[]

colorSelection[]

colorSeparator[]

colorShade[]

colorShadow[]

colorSideChannel[]

colorTextDisable[]

colorTextSelect[]

colorText[]

colorTracksFill[]

colorTracks[]

colorUnload[]

colorVehicleChannel[]

colorVersionBad[]

colorVersionGood[]

colorWizard[]

color[]

colorbackground[]

colortext[]

columns

columns[]

controlsBackground[]

controls[]

crossHairs

cueTexture

cursorLineWidth

cycleLinks

default

dirColor[]

direction[]

disabledAI

disabledAllAI

done

drawStyle

duration

east

eastLocked

eastUnlocked

emptyEq

emptyGun

emptyHGun

emptyHGunMag

emptyMag2

emptyMag

emptySec

enableDisplay

enableSimulation

enableZoom

enabledAI

enabledAllAI

faceType

fade

fadein

failed

filename

font

fontBasic

fontBold

fontClanName

fontCommand

fontDown

fontGrid

fontHelicopterHUD

fontInfo

fontLabel

fontLevel

fontNames

fontPlate

fontUnitID

fontUnits

forceArrowModel

from

getIn

guer

guerLocked

guerUnlocked

h

height

hideCursor

hideFull

hideOnUse

hidePassworded

hostLocked

hostUnlocked

hotspotX

hotspotY

icon

iconAPC

iconAir

iconArrowDown

iconArrowUp

iconCamera

iconCar

iconCheckpoint

iconHelicopter

iconLaserTarget

iconLogic

iconMan

iconMotorcycle

iconObject

iconPaperCar

iconParachute

iconPlane

iconPlayer

iconSelect

iconSensor

iconShip

iconStaticObject

iconTank

iconThing

iconVehicle

idc

idd

image

imageBusy

imageCargo

imageCommand

imageCommander

imageCornerElement

imageDefaultWeapons

imageDriver

imageEngine

imageGun

imageGunner

imageHull

imageLTrack

imageMoveAuto

imageMoveBack

imageMoveFast

imageMoveForward

imageMoveLeft

imageMoveRight

imageMoveStop

imageNextPage

imageNoWeapons

imageObsTurret

imagePrevPage

imageRTrack

imageSemaphore

imageTower

imageTurret

imageWaiting

importance

inBack

indent

leader

left

line

lineSpacing

lines

lock_target

locked

maxValue

me

memory

minValue

mission

model

modelWoman

move

moveOnEdges

moving

movingEnable

name

nextPage

none

offsetDown

offsetPressedX

offsetPressedY

offsetX

offsetY

onButtonClick

onHTMLLink

onKeyDown

onKeyUp

onKillFocus

onLBDblClick

onLBSelChanged

onLoad

onMouseButtonClick

onMouseButtonDblClick

onMouseButtonDown

onMouseButtonUp

onMouseEnter

onMouseExit

onSetFocus

onUnload

outArrow

overviewLockedMission

overviewMyMissions

overviewNewMission

package

paper1

paper2

paper3

paper4

paper5

paper6

paper7

password

period

picture

pictureHeight

pictureLaserTarget

pictureLogic

picturePaperCar

pictureParachute

pictureStaticObject

pictureThing

pictureWidth

playerKilledScript

playerRespawnOtherUnitScript

playerRespawnScript

playerRespawnSeagullScript

playerResurrectScript

positionBack[]

position[]

prevPage

priority

profilePathCommon

profilePathDefault

ptsPerSquareCLn

ptsPerSquareCost

ptsPerSquareExp

ptsPerSquareFor

ptsPerSquareForEdge

ptsPerSquareObj

ptsPerSquareRoad

ptsPerSquareSea

ptsPerSquareTxt

relativeToCursor

rowHeight

rowheight

rows

saveParams

scale

scaleDefault

scaleMax

scaleMin

scoreImage

scriptsPath

select

select_target

selected

selection

selectionArrow

selectionDate1

selectionDate2

selectionDay

selectionEyelid

selectionGlasses

selectionLBrow

selectionLMouth

selectionLip

selectionMBrow

selectionMMouth

selectionPaper

selectionPersonality

selectionRBrow

selectionRMouth

shadow

shadowColor

shadowOffset

shortcut

show

showCountourInterval

showFull

showGearOnExit

showHint

showLine

showNext

showPassworded

showWindow

sideDisabled

size

sizeCommand

sizeEx

sizeExBasic

sizeExDown

sizeExGrid

sizeExInfo

sizeExLabel

sizeExLevel

sizeExNames

sizeExUnits

sizeLeader

sizePlayer

sizeUnitID

sortDown

sortUp

soundCancel[]

soundChangeFocus[]

soundClick[]

soundCollapse[]

soundDoubleClick[]

soundEnter[]

soundEscape[]

soundExpand[]

soundFail[]

soundOK[]

soundOpen[]

soundPush[]

soundSelect[]

source

star

startupScript

statisticsLinks

stickX[]

stickY[]

Strings[]

style

tactical

teamSwitchScript

text

textDefault

textHeight

textSimple

textSize

texture0

texture90

texture180

texture270

texture

textureClear

textureCloudly

textureConnectionQualityBad

textureConnectionQualityPoor

textureDesyncHigh

textureDesyncLow

textureOvercast

textureRainy

textureStormy

thumb

timeout

to

ToolTip

tooltipColorBox[]

tooltipColorShade[]

tooltipColorText[]

top

type

uMax

uMin

underline

unitInfoTypes[]

up[]

valign

version

w

waitForLoad

watch

weapon

west

westLocked

westUnlocked

wholeHeight

width

x

xBack

xOffset

xboxStyle

y

yBack

z

zBack

zoomDuration

[Guest]

Very impressive already ColonelSandersLite.

I cant do anything else than just support you and hope you will find the time and (dont know correct syaing) "flow" to finish this project.

It will be very much appreciated by many, that is for sure

Keep it up.

[benreeper 0]

I have a widescreen monitor and all fullscreen dialogues are in "4:3", i.e. the opposite of letterbox.

--Ben

[Nutty_101 0]

I have a widescreen monitor and all fullscreen dialogues are in "4:3", i.e. the opposite of letterbox.

--Ben

Wasn't this done to ensure that the dialogs all line up correctly? So things are not all drawn out of wack. Images for example.

[ColonelSandersLite 0]

I have a widescreen monitor and all fullscreen dialogues are in "4:3", i.e. the opposite of letterbox.

--Ben

Wasn't this done to ensure that the dialogs all line up correctly? So things are not all drawn out of wack. Images for example.

Yes, definatly.

[ColonelSandersLite 0]

You wont see the bug if you use a small dialog in the middle of the screen. Try this:

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

class FullScreenBG : RscText

{

x = 0.0;

y = 0.0;

w = 1;

h = 1;

text = "";

colorBackground[] = {0, 0, 0, 0.5};

};

Then you will see that x = y = 0 is not on the upper left corner and that the background is not completely filled (if the screen ratio is not 4:3) although w and h is 1

I've found a possible solution for your problem during my research T_D. Actually, it's exactly what BIS did for the main map window. Create a panel to back it using x = -1; y = -1; w = 3; h = 3; and make it's color whatever color you should choose.

Simplified Example (Doesn't have *everything*):

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

class BIS_RscPicture

{

access = ReadAndWrite;

type = CT_STATIC;

idc = -1;

style = 48;

colorBackground[] = {0, 0, 0, 0};

colorText[] = {1, 1, 1, 1};

font = "TahomaB";

sizeEx = 0;

lineSpacing = 0;

text = "";

};

class MainBack : BIS_RscPicture

{

text = "BIS_ui_gradients\ui_gradient_start_gs.paa";

colorText[] = {1, 1, 1, 0.9};

};

class ControlBack : MainBack

{

text = "BIS_ui_gradients\ui_gradient_reverse_gs.paa";

};

class TitleBack : MainBack

{

text = "BIS_ui_gradients\ui_gradient_title_gs.paa";

colorText[] = {0.24, 0.47, 0.07, 1};

};

class FullScreen_Black_Back : MainBack

{

x = -1;

y = -1;

w = 3;

h = 3;

text = "#(argb,8,8,3)color(0,0,0,1)";

colorText[] = {0, 0, 0, 1};

color[] = {0, 0, 0, 1};

colorBackground[] = {0, 0, 0, 1};

};

// Particle Circle Dialog Section

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

{

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[] =

{

Btn_Close

};

class Btn_Close : RscButton

{

idc = 199;

text = "Close";

x = 0.8225; y = 0.897; w = 0.11; h = 0.035;

action = "closeDialog 1;";

};

};

This will give you a solid black background that will take up the whole screen regardless of screen aspect ratio. If you want to make it movable for some reason, make the background size and location x = -2; y = -2; w = 5; h = 5; and make sure the movable aspect is not applied to the black background but the panel in the 4:3 screen area instead. Change the color and such to suit your needs. It's important that you keep the controls the user has to access in the main 4:3 area though, or most users won't be able to get at them.

Short of that, if you're wanting to make controls scale to the true screen ratio, you need to know that every size related parameter of every control right down to font size is dependent on the 4:3 aspect ratio for scaling. There is no chance that BIS will make the way the percentals work change and invalidate every dialog ever made for arma, including theirs.

[ColonelSandersLite 0]

Great news! At least from my perspective... I've finished the first pass through that list up to the D's!!!

That sounds much worse than it is though, and is actually very good news. The C's are the biggest section honestly, along with the S'. Also, on this first pass, I'm having to weed out any duplicates, figure out loosely what goes where, their basic usage info, etc. There's a lot of those parameters that only apply to specific controls. A Ton of them go to the map control type for example... Of the first 137 of them, 56 where either in error or internal arma use only (and those get removed). Of the 81 left, I would say that loosely 60 are control type specific, which means I don't have to test them for all the controls.

So, to say exactly why that's positive, it dramatically reduces the amount of tests I have to do on all subsequent run throughs. Some loose calculations here:

477 items * (bad items encountered/all items encountered) * (control specific items encountered/all good items encountered) = 146 control specific items

477 items * (bad items encountered/all items encountered) - 146 control specific items = 49 generic items

(22 good usable control type (loosely) * 49 generic items) + (146 control specific items * 2 to account for the types that go on a few differenc controls) = 1370 tests to do

So, by rough estimation, I will have reduced the amount of tests needed by 12940 or 90% . See? Good news .

[Lolsav 0]

You got me tottaly confused with your math.. but i love the conclusions "90% done" :P

[ColonelSandersLite 0]

Not 90% done, 90% less work.

In actuallity, there's not too much difference between the 2 if you think about it. It means the same ETA on the research either way.