Dialog IDD's

[UNN 0]

Since we can now have addon based dialogs as well as mission based ones. There's a danger of IDD conflicts across different addons and missions? I figure something along the lines of, or derived from OFPEC tags. Would be the ideal solution?

The quickest way I can think of, to tie into OFPEC. Would be to convert the tags into a numeric value, and use that value as a base for your dialog idd's. So in the case of RKSL, using the Arma ToArray command:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">hint format["%1",toArray("RKSL")]

You would get:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">[82,75,83,76]

Which could be converted into 82758376000. Ok, seems a bit drastic, but it does work. Now we can reserve idd's from 82758376000 to 82758376999 for RKSL dialogs. I think a thousand dialogs are enough for anyone?

Alternatively we could base it on our position in the OFPEC tag list. So if for example RKSL was the 59th tag listed. We would reserve idd's from 59000 to 59999.

It doesn't really matter how you derive the idd's, as long as the chances of other people using the same one, is decreased.

[ColonelSandersLite 0]

Alternatively we could base it on our position in the OFPEC tag list. So if for example RKSL was the 59th tag listed. We would reserve idd's from 59000 to 59999.

Since they're alphabetized, that would never work.

Something that would probably work well though, is is ofpec generated a 4 digit dialog prefix for all exisiting and new tags, or let us pick one. Integration should be simple enough.

ATM though, I'm just using a very large random number...

[i0n0s 0]

I'm currently using toArray("ION") which is 737978.

Adding the additional two zeros is a good idea, so I wouldn't block IOM etc. too.

Btw: I've asked that question on OFPEC before:

Adding possibility to reserve IDDs for tags

[UNN 0]

Quote[/b] ]Since they're alphabetized, that would never work.

Something that would probably work well though, is is ofpec generated a 4 digit dialog prefix for all existing and new tags, or let us pick one.  Integration should be simple enough.

Ok, scratch that. It would be great if OFPEC could auto generate some numbers, for any current or new tag.

Quote[/b] ] I'm currently using toArray("ION") which is 737978.

Adding the additional two zeros is a good idea, so I wouldn't block IOM etc. too.

Two should be ok, I'm happy to go with that until something more organized is implemented.

[Wolfrug 0]

We discussed this over at OFPEC briefly, but we didn't come to any conclusion. However nice the idea of having insanely huge ASCII-generated numbers might seem, it's not quite as peachy as that: ArmA dialog IDDs only allow for a certain amount of numbers, since it can't take...whatever they're called. The same thing that makes a very high number in a dialog show up as 1.08374e76 and such (integers?).

Although there are still plenty enough numbers to allow for a custom number for everyone - it just won't be as easy as an ASCII conversion or such. But yes : generating a number to go with each TAG should be a priority as well! I've been using a number-replacement scheme (1 = A etc) for RUG+something else (like I for Inventory) in some of my scripted dialogs, but we'll see what turns out the best. You're welcome to head over to OFPEC as well and discuss this, I just caught sniff of this post thanks to a helpful link by another community member.

Regards,

Wolfrug

[i0n0s 0]

Another problem:

hint format["%1",toArray("RKSL")] shouldn't work as IDD because the number is going to be to large.

I have tried "ION" with added "00" and the result was that the dialog couldn't get found with that IDD.

The same goes to IDC, they can't grow that high either.

So we would need another id(d)ea ( ) to find unique IDDs.

[UNN 0]

Yeah, looks like 999999 is the limit for FindDisplay. Although Create and CloseDisplay seem to work ok with larger numbers.

[shinRaiden 0]

How many tags actually exist? I doubt over 10k. Why not just use the tag index number, and then pad 00 on the end for 100 IDD's for each of 10000 tags?

[hardrock 1]

I suppose the best solution would be if OFPEC would provide the ID range for any tag that already exists or is created in the future. The ID wouldn't really have to be connected with the tag. Like a second, auto-generated tag.

[thebarricade 7]

Isn't there already an id associated with the ofpec tag?

Like so:

http://www.ofpec.com/tags/index.php?action=details&tag_id=1627

Or does this tag_id change, and if so, why?

[UNN 0]

Quote[/b] ]Or does this tag_id change, and if so, why?

Assuming they are not reindexed or reused. Then it will certainly do for now, if you add a couple of zeros to the number. I doubt we will ever see more than 99999 tags?

The RKSL idd would then work out to be 99900 to 99999. i0n0s would be 156600 to 156699.