Layout files exsist simply to create a template that defines the structure (visual elements) of your dialog and can indeed reference race dependent assets. Once you have defined the template you will use the Hookup Dialog Item In Panel function to create a Dialog Item reference. You can then interact with this Dialog Item on a per player basis, as you would any other. All the dynamic logic for your layout, enabling/disabling buttons, show/hiding images, setting text values, etc. is still be handled by script.
There are also a lot of Dialog Item properties in layout files that the native script does not expose. An example are the frame elements Animating, AnimDuration, AnimColums, AnimCount that allow you to define sprite sheet animated images such as the autocast effect that command buttons use.
My bad, misread the part about compression. But I do agree with you there, it is kind of a silly limit. Anyway's stay on topic, I don't wish to derail your thread.
Looking forward to the finished product as I play with dialog's a lot. This might just save me the hassle of the usual trial and error I go through. Is it currently possible to save the dialogs and dialog items created into structs for later callback? If not, do you have plans for such a feature?
What do you mean by for later callback? It is not possible to generate the visual designer based on code, and I don't plan to implement it at this time.
Layout files exsist simply to create a template that defines the structure (visual elements) of your dialog and can indeed reference race dependent assets. Once you have defined the template you will use the Hookup Dialog Item In Panel function to create a Dialog Item reference. You can then interact with this Dialog Item on a per player basis, as you would any other. All the dynamic logic for your layout, enabling/disabling buttons, show/hiding images, setting text values, etc. is still be handled by script.
There are also a lot of Dialog Item properties in layout files that the native script does not expose. An example are the frame elements Animating, AnimDuration, AnimColums, AnimCount that allow you to define sprite sheet animated images such as the autocast effect that command buttons use.
And hooking from templates has its drawback now too as currently they are flawed when it comes to all properties which are exposed through galaxy natives. Why? Well, if you hook up a layout for your dialog, it will set its values correct internally, but not from the proxy part from galaxy. Hence, trying to access any of the properties you might have set such as visible/enabled/image etc. is impossible. The native functions will spit out an error back at you from them.
As such, you will also need to set the dialog properties manually upon initialization, and that renders templates almost useless in the first place.
I am aware of this problem and it is obviously an error on Blizzard's part that I have no doubt will be fixed. That being said, I have made extensive use of layouts for my UI and have yet to run into a case where I have needed to dynamically determine the default property of a dialog item. What it requires on your part is to initialize your template's items to the correct default values, dependent on the nature of your dialog, and setup your backend logic accordingly.
What do you mean by for later callback? It is not possible to generate the visual designer based on code, and I don't plan to implement it at this time.
Every dialog and dialog item has an integer handle to it, but I believe you should be aware of this. Rephrasing my question, is it possible to save these handles should there be a need to use them to modify dialog or dialog item properties dynamically in game?
For example, If there was a dialog image that represents a unit's shields. It's width will scale based on the percentage of shields remaining. But to modify the width of the dialog image, you would need to refer to the handle that represents it. I'm not sure how this would be possible if the handle were not stored into a variable or a struct upon it's initial creation.
I don't know how familiar you are with g++, but if you look in the designer, you will see that the dialog is created inside a class, and this class has a field for each dialog/button/image/etc. So referring to an image you called image1 is just writing
Newdialog*dialog=newNewdialog();dialog->image1
That will return the integer handle for the image.
If you would rather use regular galaxy, set maximum number of instance for the dialog to something, like I do in the video, then in the output script, you will see a struct with an int for each dialog/button/etc, an array of this struct, and a function that creates a dialog when given an index into that array.
Also note that everything has a "name" property, where you can change the name, if you don't like them to be image1, button1, etc.
Ah that explains it, it's OOP. That clears it up then. I'm not too familiar with g+ + as of yet and was basing my question off what I've done so far with g.
I recall they told for HotS, that they are implementing an UI designer. So far, I have seen nothing pointing towards them easing up dialog and dialog item creation. Time will tell though.
I like what you have done so far with your editor, and will certianly help that i will no longer have to test run all the time.
You are missing a few stuff IMO:
No panel dialog item type, which I find notably crucial for anchoring.
No way to faux anchor one item to another, so you can easily make, say, a button grid.
No way to properly identify which item you have selected, and resizing by dragging an edge seems to happen at random.
Dialog item attributes are not set to actual fields. Like for example, not hardcoding the image path within the constructor, but rather make it a property of the image object, in case I want to get some values from it.
Lack of a pseudo configurable grid for easy alignment.
While most of them might seem superfluous, I think you really need the panel item type
Amazing update Beier, I love it, :D. This is what Blizzard's planning on doing with the UI Module in the GalaxyEditor for HotS, but now we can use yours in the mean time, :).
BUG: the color seems to be off. its sets the property to (1,1,1,1) for white, it should be (100,100,100,100)
and the color doesn't accept random colors, the tools compiler blocks them with "could not find a method matching"
You should be able to create an action where you copy all the code in a custom code action. but i can't get it to show me the create code in the output
edit: missed the using dialogs, now it works
short galaxy free guide:
1) get the create code into the output
2) create a record and an array conatining the record
3) copy the prure create code into an text editor and replace the genereated variable name with the names of the editor (if your record has the same name, you just have to add lp_ to currentStruct, lv_ to all dialog item variables from inside the record, gv_ to the arrays name
4) create a new action with a parameter and the one action custom code action where you paste the modified code
5) call your create action somewhere and show the dialog array[x].dialog somewhere
6) profit from the awesome drag and drop system :)
@SBeier: Go
Layout files exsist simply to create a template that defines the structure (visual elements) of your dialog and can indeed reference race dependent assets. Once you have defined the template you will use the Hookup Dialog Item In Panel function to create a Dialog Item reference. You can then interact with this Dialog Item on a per player basis, as you would any other. All the dynamic logic for your layout, enabling/disabling buttons, show/hiding images, setting text values, etc. is still be handled by script.
There are also a lot of Dialog Item properties in layout files that the native script does not expose. An example are the frame elements Animating, AnimDuration, AnimColums, AnimCount that allow you to define sprite sheet animated images such as the autocast effect that command buttons use.
@SBeier: Go
My bad, misread the part about compression. But I do agree with you there, it is kind of a silly limit. Anyway's stay on topic, I don't wish to derail your thread.
Looking forward to the finished product as I play with dialog's a lot. This might just save me the hassle of the usual trial and error I go through. Is it currently possible to save the dialogs and dialog items created into structs for later callback? If not, do you have plans for such a feature?
What do you mean by for later callback? It is not possible to generate the visual designer based on code, and I don't plan to implement it at this time.
And hooking from templates has its drawback now too as currently they are flawed when it comes to all properties which are exposed through galaxy natives. Why? Well, if you hook up a layout for your dialog, it will set its values correct internally, but not from the proxy part from galaxy. Hence, trying to access any of the properties you might have set such as visible/enabled/image etc. is impossible. The native functions will spit out an error back at you from them.
As such, you will also need to set the dialog properties manually upon initialization, and that renders templates almost useless in the first place.
@Mexaprone: Go
I am aware of this problem and it is obviously an error on Blizzard's part that I have no doubt will be fixed. That being said, I have made extensive use of layouts for my UI and have yet to run into a case where I have needed to dynamically determine the default property of a dialog item. What it requires on your part is to initialize your template's items to the correct default values, dependent on the nature of your dialog, and setup your backend logic accordingly.
I have a feeling when HotS hit, this will be a non-issue. Impressive regardless :)
Every dialog and dialog item has an integer handle to it, but I believe you should be aware of this. Rephrasing my question, is it possible to save these handles should there be a need to use them to modify dialog or dialog item properties dynamically in game?
For example, If there was a dialog image that represents a unit's shields. It's width will scale based on the percentage of shields remaining. But to modify the width of the dialog image, you would need to refer to the handle that represents it. I'm not sure how this would be possible if the handle were not stored into a variable or a struct upon it's initial creation.
@FuzzYD: Go
Its all created under a referenced variable name isn't it......
Im not sure what dialogs normally look like in script .... generally In gui you do
generally I make an array for all the sub items of a dialog
@FuzzYD: Go
I don't know how familiar you are with g
++, but if you look in the designer, you will see that the dialog is created inside a class, and this class has a field for each dialog/button/image/etc. So referring to an image you called image1 is just writingThat will return the integer handle for the image.
If you would rather use regular galaxy, set maximum number of instance for the dialog to something, like I do in the video, then in the output script, you will see a struct with an int for each dialog/button/etc, an array of this struct, and a function that creates a dialog when given an index into that array.
Also note that everything has a "name" property, where you can change the name, if you don't like them to be image1, button1, etc.
@SBeier: Go
Ah that explains it, it's OOP. That clears it up then. I'm not too familiar with g+ + as of yet and was basing my question off what I've done so far with g.
@SouLCarveRR: Go
Yeah it is. Script allows direct assignments though.]] int d = NewDialog(etc,etc,etc)
int di = NewDialogItem(d,etc,etc,etc)
No need for DialogLastCreated() or DialogItemLastCreated().
Arrays work too, but I prefer struct's because they allow you to group together related variables.
@progammer: Go
I recall they told for HotS, that they are implementing an UI designer. So far, I have seen nothing pointing towards them easing up dialog and dialog item creation. Time will tell though.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI like what you have done so far with your editor, and will certianly help that i will no longer have to test run all the time.
You are missing a few stuff IMO:
While most of them might seem superfluous, I think you really need the panel item type
Go play Antioch Chronicles Remastered!
Also, coming soon, Antioch Episode 3: Thoughts in Chaos!
Dont like mapster's ugly white? Try Mapster's Classic Skin!
-
View User Profile
-
View Posts
-
Send Message
ModeratorsAmazing update Beier, I love it, :D. This is what Blizzard's planning on doing with the UI Module in the GalaxyEditor for HotS, but now we can use yours in the mean time, :).
I just saw the latest news, and this is simply awesome!
I'd wish i would know how to work with the script to be able to use it. :(
There isn't any way to use it as a gui-only mapper, is there?
BUG: the color seems to be off. its sets the property to (1,1,1,1) for white, it should be (100,100,100,100)
and the color doesn't accept random colors, the tools compiler blocks them with "could not find a method matching"
@PatchOne: Go
You should be able to create an action where you copy all the code in a custom code action. but i can't get it to show me the create code in the output
edit: missed the using dialogs, now it works
short galaxy free guide:
1) get the create code into the output
2) create a record and an array conatining the record
3) copy the prure create code into an text editor and replace the genereated variable name with the names of the editor (if your record has the same name, you just have to add lp_ to currentStruct, lv_ to all dialog item variables from inside the record, gv_ to the arrays name
4) create a new action with a parameter and the one action custom code action where you paste the modified code
5) call your create action somewhere and show the dialog array[x].dialog somewhere
6) profit from the awesome drag and drop system :)