Aha yes, that would be it. How would I go about doing so?
You cant. A bitflag preset is an integer. Strings and integers are completely different types. You would have to contruct the preset manually by using an if then else.
The function returns true if all flags of "Mask" are 1 within "Bitflag".
You can also create a more generic function taking two integer parameters and then use it with "Convert Preset To Integer" to be able to check any bitmask type.
Just like in other languages, bitflags are implemented using a numeric type (in this case: integer) and using bitwise operators.
Example:
intmouse_bitflag=c_mouseButtonFlagLeft|c_mouseButtonFlagRight|c_mouseButtonFlagXButton2;if(mouse_bitflag&c_mouseButtonFlagXButton2){//XButton2 is pressed}else{//XButton2 is not pressed}
One can also use the byte type if no more than 8 flags are required.
A workaround for your problem would be to use Triggers instead of function pointers. They are fully supported in GUI and data tables.
Triggers are not as effective, however, they can be used to simulate functions. Parameters can be passed by setting a global variable directly before the trigger call and then assigning that global variable to a local variable inside the trigger before any other operations. (This is actually what Blizzard does when checking the "Create Thread" flag for a custom action)
Its not perfect but thats the technique I'm using since a long time (GUI doesnt support funcrefs at all) and it works really well. Almost all my systems are based on this technique (Including chat messages. :D )
About the whole data tables vs global struct discussion, I think its really just a matter of personal preferrence. I prefer wasting a little bit of global memory space over the pitfalls of data table programming in most cases.
Also, here is something to think about:
Its not clear how much memory the data table itself consumes when using it extensively.
Lets say I have a struct with 10 members of mixed types, mostly booleans and ints. If i create a global array of 1000 structs and only use 700 of them, I wasted memory for 300 of those structs. However, if I created the same construct using data tables the 700 existing entries may consume more internal memory than my 1000 structs, as the data table needs to store way more internal information (Mapping string keys to data). In this case, an additional 10*700 = 7000 strings need to be saved as keys to access the stored data (aka "struct members").
Assuming that ints and booleans each require 4 bytes of memory in Galaxy, The 1000 global structs would require approximately 1000*10*4 = 40000 bytes of memory, or approx 40KB.
With an average key length of 10 chars and 1 byte of required memory per character within strings, the data table would require at least (I say "at least" because it may be more based on string encoding) 700*10*10 = 70000 bytes (70KB) of memory just for storing the identifiers, plus the additional memory required to store the actual values. So even though we stored less information and did not "waste" any memory we still end up with more internal memory consumption overall.
Even though this memory consumption is not visible in the debugger it still exists internally and most likely increases memory usage of the map. Is it a big deal and does it matter? Probably not! But same goes for unused structs. It is something to keep in mind if talking about efficiency.
While that absolutely works I found myself going back to just global struct arrays for most things, simply because its very tedious (especially in GUI!) and error prone to code based on data tables. For example you have to make sure that:
- When adding a new field to the "constructor" one has to make sure that it also gets deleted from the data table in the destructor, otherwise there will be resource leaks (Btw, those leaks are hard to find unless debugging the data table manually by constantly reading its value count, and even then its hard to figure out which value specifically is causing the problem)
- Always using the correct key identifiers (make sure to have no typos, maybe even use const variables to store all the key information, which means additional work)
- Data table is slower than normal variables, plus there are also many other factors slowing down this approach, such as repeating string concatination for data table keys, counters, existance checks etc.
- Needs convenience methods to access various fields (In your example smth. such as "getName()"), because its way more work to read them compared to just reading a struct member
- Bloats code size
- It can be harder to debug in the trigger debug window as the data table information is not directly accessable without reading it into a local variable first
Really, the only advantage of this approach is the dynamic memory allocation, which is why I only use it if i absolutely need it, for example if i cant know how many entries of a certain type exist. For most other things I just define a global struct array and hand-tune its size so it fits well.
That probably makes any experienced programmer cringe, but sometimes one just needs to do what works best in a real scenario. :D
That said though, I am using data tables heavily myself, for example in my container library to provide dynamic storage. Data tables are probably the best feature of the language next to the ability to work with XML.
I played around with the settings a little bit (Max background size, Text alignment etc.) but wasnt able to resolve the issue.
Seems like we just have to wait until Blizzard fixes this, not exactly sure what the problem is, it appears that the internal text tag label size is not calculated correctly when using certain characters and therefor the text gets either cut off or doesnt show up at all sometimes.
You are absolutely right here, I completely forgot about the reference/immutable thing here. Strings do not get copied when assigning them to a variable.
Anyways, I still think it should be possible to change parameter values in GUI as otherwise it sometimes makes it necessary to create redundant local variables and perform unnecessary operations. I believe its easy to "hack" it though by using Set Variable and specifying the parameter (in custom script).
Blizzard probably thought it would be confusing to be able to alter parameters via "Set Variable" or there are other reasons I'm unaware of.
I agree. The macro system is a great feature and actually its something that can make GUI more powerful than Galaxy to some extend, just like using "Presets". (For example, it allows inline functions) It definately requires more documentation and examples.
About returning and storing references, I made some more quick tests yesterday, appearantly its NOT possible to store or return array- and structrefs, it only works for funcrefs. It sort of makes sense because otherwise one could attempt to return a reference to a local variable or similar.
Noticed the same problem in my project since a while.
I'm not sure if its some sort of new bug introduced in a recent patch or if they changed something about the configuration of text tags.
Nice find. I noticed the #IFHAVESUBFUNCS macro several months ago but wasnt able to get it working in my tests.
That really makes me wonder why its not used in the default if then else construct. Even though it doesnt directly influence performance it can have quite a significant impact on code length in very large projects using thousands of conditional statements, plus it makes the code easier to read.
Im wondering if there is any easy way to replace all standard if then else conditions with the more intelligent version. I took a look at the Triggers.xml file earlier today but appearantly a simple find replace is not enough. Will have to dig deeper there.
As far as performance goes, GUI does not come with a significant penalty, but there are quite some cases where custom script can be faster. A classical example is a boolean check, which always compiles to (boolean == true) instead of just (boolean), unless using a custom defined macro. For loops also compile in a pretty bad way because they need to work for positive and negative increments, therefore the loop needs to evaluate way more conditions than necessary with every run. There are also several other details such as not being able to set the value of a function parameter within the function, which is perfectly legal in Galaxy. (This is mainly a problem for large types such as Strings, as it makes it necessary to copy the string just to change it.)
Obviously all those things arent a big deal, it would still be nice to have a better Galaxy Script quality overall, especially because it seems to be quite easy to fix in many cases and would benefit all projects.
The problem is, even though you can define, lets say, your own custom "if then" construct, it is not possible to define an intelligent "if then else" that automatically omitts the "else" part if its empty. So if you wanted to add an else branch later on you would have to exchange "if then" with "if then else" by hand, which makes it practically useless. (This is also most likely the reason Blizzard kept the "if then" construct private)
Similar problems apply to for loops and all sorts of other constructs. One could define a perfect for loop for positive and negative increments, but not both.
To fix this we would need a more intelligent macro system which can check parameter values and use different galaxy code for specific cases.
As far as custom comments go, they definately do not transfer to script. I think the best solution would be to make this an optional setting and let the modder choose what he prefers.
While ranting, it would also be nice if the GUI to Galaxy compiler would get a little bit more intelligent.
For loops, unused else brackets, boolean checks etc. could be improved. It would also be awesome if GUI comments could transfer over to script (Instead of always having the same, unneccesary automatic comments such as "Variable initialisation", "Variable declaration" and such).
0
You cant. A bitflag preset is an integer. Strings and integers are completely different types. You would have to contruct the preset manually by using an if then else.
0
I'm a little bit confused about what you are trying to do.
Are you asking how to convert a string into a bitflag preset?
0
It is possible. Use the following function:
The function returns true if all flags of "Mask" are 1 within "Bitflag".
You can also create a more generic function taking two integer parameters and then use it with "Convert Preset To Integer" to be able to check any bitmask type.
Example usage and output:
Output:
0
Just like in other languages, bitflags are implemented using a numeric type (in this case: integer) and using bitwise operators.
Example:
One can also use the byte type if no more than 8 flags are required.
0
Can anyone verify this?
- Uploading with at least one file in the import manager fails
- Uploading without any imported files works
0
Please provide more details. Whats your operating system? Did you already try to reinstall the game? Cleared registry keys?
0
@MasterWrath: Go
A workaround for your problem would be to use Triggers instead of function pointers. They are fully supported in GUI and data tables.
Triggers are not as effective, however, they can be used to simulate functions. Parameters can be passed by setting a global variable directly before the trigger call and then assigning that global variable to a local variable inside the trigger before any other operations. (This is actually what Blizzard does when checking the "Create Thread" flag for a custom action)
Its not perfect but thats the technique I'm using since a long time (GUI doesnt support funcrefs at all) and it works really well. Almost all my systems are based on this technique (Including chat messages. :D )
About the whole data tables vs global struct discussion, I think its really just a matter of personal preferrence. I prefer wasting a little bit of global memory space over the pitfalls of data table programming in most cases.
Also, here is something to think about:
Its not clear how much memory the data table itself consumes when using it extensively.
Lets say I have a struct with 10 members of mixed types, mostly booleans and ints. If i create a global array of 1000 structs and only use 700 of them, I wasted memory for 300 of those structs. However, if I created the same construct using data tables the 700 existing entries may consume more internal memory than my 1000 structs, as the data table needs to store way more internal information (Mapping string keys to data). In this case, an additional 10*700 = 7000 strings need to be saved as keys to access the stored data (aka "struct members").
Assuming that ints and booleans each require 4 bytes of memory in Galaxy, The 1000 global structs would require approximately 1000*10*4 = 40000 bytes of memory, or approx 40KB.
With an average key length of 10 chars and 1 byte of required memory per character within strings, the data table would require at least (I say "at least" because it may be more based on string encoding) 700*10*10 = 70000 bytes (70KB) of memory just for storing the identifiers, plus the additional memory required to store the actual values. So even though we stored less information and did not "waste" any memory we still end up with more internal memory consumption overall.
Even though this memory consumption is not visible in the debugger it still exists internally and most likely increases memory usage of the map. Is it a big deal and does it matter? Probably not! But same goes for unused structs. It is something to keep in mind if talking about efficiency.
0
Just downloaded patch 2.1.7 freshly from SEA servers, issue persists. :(
0
@MasterWrath: Go
While that absolutely works I found myself going back to just global struct arrays for most things, simply because its very tedious (especially in GUI!) and error prone to code based on data tables. For example you have to make sure that:
- When adding a new field to the "constructor" one has to make sure that it also gets deleted from the data table in the destructor, otherwise there will be resource leaks (Btw, those leaks are hard to find unless debugging the data table manually by constantly reading its value count, and even then its hard to figure out which value specifically is causing the problem)
- Always using the correct key identifiers (make sure to have no typos, maybe even use const variables to store all the key information, which means additional work)
- Data table is slower than normal variables, plus there are also many other factors slowing down this approach, such as repeating string concatination for data table keys, counters, existance checks etc.
- Needs convenience methods to access various fields (In your example smth. such as "getName()"), because its way more work to read them compared to just reading a struct member
- Bloats code size
- It can be harder to debug in the trigger debug window as the data table information is not directly accessable without reading it into a local variable first
Really, the only advantage of this approach is the dynamic memory allocation, which is why I only use it if i absolutely need it, for example if i cant know how many entries of a certain type exist. For most other things I just define a global struct array and hand-tune its size so it fits well.
That probably makes any experienced programmer cringe, but sometimes one just needs to do what works best in a real scenario. :D
That said though, I am using data tables heavily myself, for example in my container library to provide dynamic storage. Data tables are probably the best feature of the language next to the ability to work with XML.
0
I played around with the settings a little bit (Max background size, Text alignment etc.) but wasnt able to resolve the issue.
Seems like we just have to wait until Blizzard fixes this, not exactly sure what the problem is, it appears that the internal text tag label size is not calculated correctly when using certain characters and therefor the text gets either cut off or doesnt show up at all sometimes.
0
@ImperialGood: Go
You are absolutely right here, I completely forgot about the reference/immutable thing here. Strings do not get copied when assigning them to a variable.
Anyways, I still think it should be possible to change parameter values in GUI as otherwise it sometimes makes it necessary to create redundant local variables and perform unnecessary operations. I believe its easy to "hack" it though by using Set Variable and specifying the parameter (in custom script). Blizzard probably thought it would be confusing to be able to alter parameters via "Set Variable" or there are other reasons I'm unaware of.
@ArcaneDurandel: Go
I agree. The macro system is a great feature and actually its something that can make GUI more powerful than Galaxy to some extend, just like using "Presets". (For example, it allows inline functions) It definately requires more documentation and examples.
About returning and storing references, I made some more quick tests yesterday, appearantly its NOT possible to store or return array- and structrefs, it only works for funcrefs. It sort of makes sense because otherwise one could attempt to return a reference to a local variable or similar.
0
Noticed the same problem in my project since a while. I'm not sure if its some sort of new bug introduced in a recent patch or if they changed something about the configuration of text tags.
Anyone knows more about this?
0
Nice find. I noticed the #IFHAVESUBFUNCS macro several months ago but wasnt able to get it working in my tests.
That really makes me wonder why its not used in the default if then else construct. Even though it doesnt directly influence performance it can have quite a significant impact on code length in very large projects using thousands of conditional statements, plus it makes the code easier to read.
Im wondering if there is any easy way to replace all standard if then else conditions with the more intelligent version. I took a look at the Triggers.xml file earlier today but appearantly a simple find replace is not enough. Will have to dig deeper there.
As far as performance goes, GUI does not come with a significant penalty, but there are quite some cases where custom script can be faster. A classical example is a boolean check, which always compiles to (boolean == true) instead of just (boolean), unless using a custom defined macro. For loops also compile in a pretty bad way because they need to work for positive and negative increments, therefore the loop needs to evaluate way more conditions than necessary with every run. There are also several other details such as not being able to set the value of a function parameter within the function, which is perfectly legal in Galaxy. (This is mainly a problem for large types such as Strings, as it makes it necessary to copy the string just to change it.)
Obviously all those things arent a big deal, it would still be nice to have a better Galaxy Script quality overall, especially because it seems to be quite easy to fix in many cases and would benefit all projects.
0
The problem is, even though you can define, lets say, your own custom "if then" construct, it is not possible to define an intelligent "if then else" that automatically omitts the "else" part if its empty. So if you wanted to add an else branch later on you would have to exchange "if then" with "if then else" by hand, which makes it practically useless. (This is also most likely the reason Blizzard kept the "if then" construct private)
Similar problems apply to for loops and all sorts of other constructs. One could define a perfect for loop for positive and negative increments, but not both.
To fix this we would need a more intelligent macro system which can check parameter values and use different galaxy code for specific cases.
As far as custom comments go, they definately do not transfer to script. I think the best solution would be to make this an optional setting and let the modder choose what he prefers.
0
While ranting, it would also be nice if the GUI to Galaxy compiler would get a little bit more intelligent.
For loops, unused else brackets, boolean checks etc. could be improved. It would also be awesome if GUI comments could transfer over to script (Instead of always having the same, unneccesary automatic comments such as "Variable initialisation", "Variable declaration" and such).