The call command and Groups?

[Viper-SWE- 0]

Does the call command work with groups too?

I want to add a certain group to a lists data, and then in another script get an array with all the units of that group.

First:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">lbAdd[1303, format["%1", group _unit]]

Second:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">call format["selectedUnits = units %1", lbData [1303, lbCurSel 1303]]

I only get an error message that says:

Quote[/b] ]'selectedUnits = units WEST |#|Alpha Black': Error Unknown operator Alpha

Can't 'call' handle groups or what am I doing wrong?

[General Barron 0]

Lemme see if I can explain this without causing more confusion...

Your problem is you are confusing a data type with the string representation of that data type.

The call command just executes a line of code, the same kind that is typed a script. Using the format command just "types" something into the script dynamically during runtime (instead of ahead of time).

The format command will print out the string representation of a data type. But this is NOT the stuff you need to type into a script in order to use this data type.

So, during runtime, this line of code here:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">call format["selectedUnits = units %1", lbData [1303, lbCurSel 1303]]

Tries to execute a line of code that looks exactly like this:

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

If you typed that into a script, it would not work, because typing "WEST Alpha Black" doesn't follow proper scripting syntax. Nor will it work if you "type" it into a script via the call + format commands.

This confusion arises because for SOME data types, the string representation is the same as what you would type into a script to refer to that data (examples: numbers, strings, sides). But this isn't true for ALL data types (examples: groups, objects)!

-------To fix it----------

This might be tough, because of the limited scripting commands available for dialogs. What you are trying to do is to "store" a GROUP into a listbox. But the commands we have for listboxes only store STRINGS.

As mentioned before, the string representation of a group can NOT be 'typed' into a script during runtime in order to refer to that group.

So you are going to have to be creative to find a workaround. Don't you just love OFP scripting .

Here is one possibility:

When you fill up this listbox with the string representations of the groups, you also make a (temporary) global variable, which will be filled with the actual groups. The group that goes in the first index of the listbox will also go in the first group of the global array. So it would work kinda like this:

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

grouplist_groups = []

lbAdd [0, format["%1", group1]

grouplist_groups = grouplist_groups + [group1]

lbAdd [1, format["%1", group2]

grouplist_groups = grouplist_groups + [group2]

...etc etc

Obviously you would want to use a loop instead of typing it all out like that.

Next, when the player selects a group from the listbox, you read what index he has selected, and you pull the group from the global array (instead of from the listbox, like you are trying to do):

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">selectedUnits = units (grouplist_groups select (lbCurSel 1303))

It's an ugly workaround, but it should work. If you are making a big dialog/script, just make sure to comment your code well, and document your global variables somewhere. That way this messy code won't get overwhelming, especially if you return to it after a while.

[Viper-SWE- 0]

Thanks a lot for your reply!

I hoped that the call-command somehow interpreted a string and converted it to the right data type, and that I just had written it the wrong way. Now I know it don't...

This whole thing was just about that I wanted to use the new call-command to make a neat solution (I did the work-around thingy in my first try), but I guess I have to go with the old, ulgy one!

You're so right - Ofp-programming is all about work-arounds!