SC2Mapster

Then make a global variable which contains the current unit type, and make the trigger from above create one of that unit type.

In a separate trigger, like for instance a periodic 60 seconds trigger, you change that global variable to reflect what unit type should be created.

Well, for just a few buttons, the gain might not be so significant, but what you would do is add the following line after creating your button.

TriggerAddEventDialogControl(<trigger>, c_playerAny, <button>, c_triggerControlEventTypeClick);

That function will register the event to the trigger, but in this context, we can specify exactly which button should run the trigger. You need to find the name of the trigger variable for the trigger that should be called, and you need the button that you created. For the trigger name, the easiest way to find it is to look at the custom script for the GUI code (ctrl+F11). Look for a global variable declaration of type trigger under the section trigger variables. The name should look somewhat like the name of your trigger. For example, for the melee init trigger, the line would be

trigger gt_MeleeInitialization;

And then you know that the trigger variable name is gt_MeleeInitialization.

To get the value for the <button>, you could probably call DialogControlLastCreated().

It can.. use the event Dialog Item is used. For pure GUI, you will need to add a condition to check that it was the right dialog item that was used (unless you only have one dialog item that can be used), so it will have to be saved in a global variable.

If you are willing to go a bit into custom scripting, there is a more efficient way that doesn't require global variables.

Like you figured out how to make buttons, you can make labels. You can set a text for them to display, and you can change the font and color of the text.

Look for Dialog - Create Dialog Item (Label). They require a dialog to be attached to though, so you need to create that first (remember to show it too).

For tutorials.. just doing a quick search on dialogs, I found that there are some tutorials called Really great looking dialogs. I havent read them, but they will probably help.
http://www.sc2mapster.com/forums/?scope=tree&search=Really+Great+Looking+Dialogs

The problem with such a function is that the name varies depending on the language of SC II. That is why you only have a function that will return it as a text (Unit Type - Unit Type of Unit).
You should still be able to use that to print it to chat or save it in a bank (as a text).

I think that the only alternative is to make a function with a giant if over your relevant unit types.

What Eiviyn means is that you should make a trigger like this

Events
    Map init
Conditions
Actions
    Repeat Forever
        Create Unit
        Wait X seconds

I think you'll have more luck getting his attention if you send him a pm rather than resurrecting a random thread started by him.

Best setup I could come up with is this (use the catalog to get/set the price)

Increase zealot cost
    Events
        Unit - Any Unit is issued an order to Gateway - Warp In Zealot
    Local Variables
        price = 0 <Integer>
    Conditions
    Actions
        Variable - Set price = (Value of Units "Zealot" "CostResource[Minerals]" for player (Triggering player) as an integer)
        Variable - Modify price: + 25
        Catalog - Set value of Units "Zealot" "CostResource[Minerals]" for player (Triggering player) to (String(price))

Decrease zealot cost
    Events
        Unit - Any Unit is issued an order to  Cancel - Slot
        Unit - Any Unit is issued an order to  Cancel
    Local Variables
        price = 0 <Integer>
    Conditions
    Actions
        Variable - Set price = (Value of Units "Zealot" "CostResource[Minerals]" for player (Triggering player) as an integer)
        Variable - Modify price: - 25
        Catalog - Set value of Units "Zealot" "CostResource[Minerals]" for player (Triggering player) to (String(price))

First trigger will increase the cost of a zealot for triggering player when he issues an order to train a zealot, and the second one will decrease it again when he cancels. The only downside with this system is that the building training the unit can't be allowed to train other units - otherwise canceling them would decrease the cost of a zealot.

Another solution is to use the events for Unit Training progress started/canceled. That will work for multiple unit types trained at the building, but you would need to restrict the queue size to one, since the price is only adjusted for the unit who is actually being trained (not queued). So if there was a queue of 5, the player could train 4 zealots in a row with the same price.

@Thenarden: Go

Yeah, I know it might be less efficient for many units - that is what I meant by the last section about implementing a more complex data structure based on stuff like unit type and owner.

However, I won't go into details about that, since it is already complex enough as it is. First make it work, then optimize if efficiency is a problem. Creating unnecessary complex data structures just gives you lots of bugs.

I managed to do what I believe you want. I did it using galaxy++ though, since that was way easier for dynamic arrays and such.

I split it into 3 script files - two utility files, and the map script. I attached them along with the output map and the raw galaxy script.
I know this is the GUI forum, but I just won't write all the GUI needed to do this, so I hope you are at least somewhat familiar with programming or galaxy.

If you plan to use it for a lot of units, I suggest adding a trigger that remove units/timers from the dictionary when the unit dies.

In case you want to make this in GUI, you can make dynamic arrays using the data table. The list is just a convenient wrapper around a dynamic array in G++. The dictionary uses two lists - in our case, a list of units and a list of their corresponding timers. Such that index i of the unit list is "linked" with index i of the timer list.

When a unit becomes idle, I then check if we had already created a timer for that unit by running through the unit list looking for our unit. If no timer was created, create one, add an event to the TimerEnd trigger (requires custom script), and add the unit and list to the dictionary. Next, start the timer as a 10 second non periodic timer.

When a unit is no longer idle, you first need to check if we had created a timer for that unit (again, run throught the unit list). If a timer had been created, pause it.

When the timer expires, you can fetch the unit from your dictionary by looking for the Triggering Timer.

All right.. We do a lot of running through a list, which takes linear time in the number of elements in the list. So if you use this system for many units, try to delete them from the lists when they die. Also, you can use constant data about the unit to make a more complex, and faster data structure (like unit type, owner and such). But if you are not that much into programming, it might be best to just stick with the arrays.

In my opinion, I would prefer a reliable solution over a transparent solution that doesn't always return the right value.

But, for my current needs, the library is fine as it is, so I wouldn't update to the newest version anyway.

It works fine on battle.net - I use it myself.. Just ask people to hold down their mouse for a sec to account for the lag.

@JakeCake26: Go

You can position a dialog according to the UI coordinates.
http://www.sc2mapster.com/forums/development/gui/24076-placing-dialogs-at-mouse-click-position
That might give you a more elegant solution.

Yeah, I might do that in a future update. For now at least, it should be up to date.

Right - sorry about that. I'll get on it.

It does require a new update, since the native lib is precompiled. If it wasn't precompiled, it would take a couple of seconds to compile it when the app launches - which I found unacceptable.