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.
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.
I would say if you have the physical designer in working condition you have half of the work done and would just require some backend work to implement Layouts. I would very much like to see a UI designer that makes use of the SC2Layout implementation. This allows for greatly reduced script overhead. A complex dialog item made up of hundreds of images, buttons, etc. requires only one line of script to create. You can also make use of SC2Font files and link to the Asset.txt instead of referencing assets directly. Seperation of these facets greatly simplifies multi-user projects. A team member working on UI layout does not interfere with someone working on script. Asset references in the Assets.txt allows chopping and changing of content without breaking UI/Script that relies upon it.
Every element of the game UI, most notebly story mode interfaces, are defined as SC2Layouts. You can be sure they provide a lot more flexability than script.
If you're interested, you can look at a project I put up a few days ago which is an XML schema for SC2Layouts. If you can make sense of it you will get a very good idea of how Layout files are structured.
Is the pick each unit meant to be picking units only belonging to player 1? Seems to be you want to be picking units belonging to the player found in the "Picked Player" function.
I think it's a cute idea, and I'm certain that you know better than us what your girlfriend likes/doesn't like. I would be interested in helping you with your project, however I would need more details. I have sent you a PM and, if you like, you can reply to me here or at the e-mail I provided.
Rossili seems to have a bit of a history with regards to fraudulant and unfounded claims. I will believe it when the rest of the scientific community gives it the green light.
If you have $8000 dollars for a budget you don't need any advice on what to get. Go the nearest computer store, find where they keep the most expensive, cutting edge hardware and buy one, or more, of each type.
If you want a serious break down of every piece of hardware to ensure maximum performance with minimum bottlenecking in any one department, you can paypal me a bite of that $8000.
Mmmmm, clever idea. With regards to multiple quads/textures, does an M3 file have any sort of limit with regards to the number of seperate textures it can address? The single sprite sheet does sound better, though I wonder if it will work. I have no experience with 3DSMax or the M3 format, perhaps there are some other experienced opinions out there?
I don't have a lot of technical know how with regards to what the M3 format is capable of so I am hoping one of the more experienced artists could shed some insight. I've looked through a bunch of exsisting artwork and I can't find any that use animated textures. Does anyone know if it is possible to fake animated 2D artwork in the M3 format?
I play a fair distance from Blizzard's servers, as do many of their player base, and so my latency sits in what I would assume is the 250ms-300ms range. "Optimising" input is all well and good but I guarantee you, any bottle neck you think occurs (and it most certainly does not) will not take anywhere near that amount of time for Blizzard's servers to process.
The game server already processes tens if not hundreds of thousands of calculations every frame and an addtional 98 key checks (any programmer worth his salt would be able to do this with no checks) are but a drop in the bucket. Even IF there was any sort of overhead from this calculation it would pale in comparison to my standard 300ms travel time between the server and I.
I can tell you right now that with 300ms delay between input and movement this map would become completely unplayable for me and anyone else in my position.
0
@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.
0
@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.
0
@SBeier: Go
I would say if you have the physical designer in working condition you have half of the work done and would just require some backend work to implement Layouts. I would very much like to see a UI designer that makes use of the SC2Layout implementation. This allows for greatly reduced script overhead. A complex dialog item made up of hundreds of images, buttons, etc. requires only one line of script to create. You can also make use of SC2Font files and link to the Asset.txt instead of referencing assets directly. Seperation of these facets greatly simplifies multi-user projects. A team member working on UI layout does not interfere with someone working on script. Asset references in the Assets.txt allows chopping and changing of content without breaking UI/Script that relies upon it.
Every element of the game UI, most notebly story mode interfaces, are defined as SC2Layouts. You can be sure they provide a lot more flexability than script.
If you're interested, you can look at a project I put up a few days ago which is an XML schema for SC2Layouts. If you can make sense of it you will get a very good idea of how Layout files are structured.
SC2Layout XML Schema
0
@SouLCarveRR: Go
Does this make use of script or layout files?
0
@CrazyTwigman: Go
Is the pick each unit meant to be picking units only belonging to player 1? Seems to be you want to be picking units belonging to the player found in the "Picked Player" function.
0
@Monorey: Go
I think it's a cute idea, and I'm certain that you know better than us what your girlfriend likes/doesn't like. I would be interested in helping you with your project, however I would need more details. I have sent you a PM and, if you like, you can reply to me here or at the e-mail I provided.
0
This is an XML schema file that will power the intellisense of your XML editor of choice and make your UI modification a whole lot easier.
You can refer to the project page for details and a link to the file.
SC2Layout XML Schema
0
@caparosmith: Go
Rossili seems to have a bit of a history with regards to fraudulant and unfounded claims. I will believe it when the rest of the scientific community gives it the green light.
0
@iSaintx: Go
If you have $8000 dollars for a budget you don't need any advice on what to get. Go the nearest computer store, find where they keep the most expensive, cutting edge hardware and buy one, or more, of each type.
If you want a serious break down of every piece of hardware to ensure maximum performance with minimum bottlenecking in any one department, you can paypal me a bite of that $8000.
0
Do you want any visual changes to the structure or is your goal simply to prevent it from constructing units?
0
@Zarakk: Go
I have looked at the existing methods for dealing with 2D sprites but am looking specifically to make use of the M3 format.
0
@Frizi: Go
Sounds like a good place to start, thanks.
0
@Frizi: Go
Mmmmm, clever idea. With regards to multiple quads/textures, does an M3 file have any sort of limit with regards to the number of seperate textures it can address? The single sprite sheet does sound better, though I wonder if it will work. I have no experience with 3DSMax or the M3 format, perhaps there are some other experienced opinions out there?
Thanks. :)
0
I don't have a lot of technical know how with regards to what the M3 format is capable of so I am hoping one of the more experienced artists could shed some insight. I've looked through a bunch of exsisting artwork and I can't find any that use animated textures. Does anyone know if it is possible to fake animated 2D artwork in the M3 format?
0
@Nebuli2: Go
I play a fair distance from Blizzard's servers, as do many of their player base, and so my latency sits in what I would assume is the 250ms-300ms range. "Optimising" input is all well and good but I guarantee you, any bottle neck you think occurs (and it most certainly does not) will not take anywhere near that amount of time for Blizzard's servers to process.
The game server already processes tens if not hundreds of thousands of calculations every frame and an addtional 98 key checks (any programmer worth his salt would be able to do this with no checks) are but a drop in the bucket. Even IF there was any sort of overhead from this calculation it would pale in comparison to my standard 300ms travel time between the server and I.
I can tell you right now that with 300ms delay between input and movement this map would become completely unplayable for me and anyone else in my position.