Yeah, I agree - it should do implicit casts in method calls.. which it now does :)
Edit:
@Mexaprone: Go
Folders are gray unless there is an enabled file in them.. When they are empty, they aren't really used in the compilation process. Enabling/disabling a folder just applies the setting to all files in the folder, so doing it on an empty folder doesn't really do anything - I could make it impossible.
The reason for the spaces afterwards is that the component I'm using for the treeview messes up the with of nodes when they are bold. The with is still calculated as if the text wasn't bold. So it's either spaces after the bold text, or having the text cut off because the node is too short - try making a really long project name to see what I mean (like abcdefghijklmnopqrstuvwxyz).
When you experience inconsistent enabled states, are you by any chance moving the program to another place on the harddisk, or renaming the project?
This is just a design choise. I didn't see much reason for the ability to collapse the projects node, so I added everything to the root.
I hadn't noticed :) I shall fix
Yeah, I did notice that. It's only a visual bug though.. but still :)
I did that for files, actually - forgot doing it for projects.
Yeah - didn't consider that
Well, the compiler just chooses some file to be the root file, and if you choose 1 output file, everything is put into that file, and all other files are removed.. The code generation phase works the same regardless of if one output file was chosen.. hence the name.. Still, I can check and rename it to mapscript.
Windows consists of a lot of underlying systems with a pretty gui on top. The file system can handle files called " .foo".. I guess it just needs a unique string. Windows explorer doesn't like it though. But since I obviously don't create files through windows explorer, it's easy to create files like that. Another example is that you can create files with a path longer than 260 characters if you don't use windows explorer.. but explorer can't navigate to them, or delete them.. at least, I overheard people talking about that at school :)
3)
Yeah, guess it would be more intuitive to have it created inside.
I shall fix
PS stuff: I guess my screen is so big that it doesn't bother me that the object browser takes up space. I'll make it optional.
Edit:
How are things going with that dialog system?
Yes.. that would be the simple way to do it :)
The only down side is that such a trigger would execute each time any unit dies. But if you don't have too many threads due to sudden unit deaths, then it's probably not a problem.
Events are registered when the map loads. At that time, your initialization trigger has not yet run, so your array is not initialized. As a result, you'r not registering the correct unit. The only way to go around that is to add a piece of custom script code that adds the event from your initilization trigger
If that map initialization trigger is located in a library, it is a little more difficult, since I don't think you will be able to refer to the defeat trigger from there, unless it is also in the same library. If it's outside, make an initialization trigger outside the library, and put the custom script there - events for library triggers are registered before events for non library triggers, so they should run in the proper order.
If your overseer variable is in the library, then the name of the variable changes a bit. Maybe it will be lib1_gv_overseer.. If not, you will have to look for the right name in the custom script code for your library (ctrl+F11).
6 hours and lots of tests later, I got something that seems like it works.
In case anyone else could use it..
voidGetYawPitchRoll(pointforward,pointup,outfixedyaw,outfixedpitch,outfixedroll){pitch=ASin(-forward.z);fixedcosPitch=SquareRoot(1-forward.z*forward.z);//Check if we are looking straight up or downif(cosPitch==0||AbsF(forward.z)>=1){if(pitch>0){yaw=0;roll=ATan2(-up.y,-up.x)+180;}else{yaw=0;roll=-ATan2(up.y,up.x)+180;}}else{fixedcosYaw=forward.x/cosPitch;fixedsinYaw=forward.y/cosPitch;yaw=ATan2(sinYaw,cosYaw);fixedcosRoll=up.z/cosPitch;fixedsinRoll;if(AbsF(cosYaw)<AbsF(sinYaw)){sinRoll=-(up.x+forward.z*cosRoll*cosYaw)/sinYaw;}else{sinRoll=(up.y+forward.z*cosRoll*sinYaw)/cosYaw;}roll=ATan2(sinRoll,cosRoll);}//Keep all angles in [0, 360]if(yaw<0)yaw+=360;elseif(yaw>=360)yaw-=360;if(pitch<0)pitch+=360;elseif(pitch>=360)pitch-=360;if(roll<0)roll+=360;elseif(roll>=360)roll-=360;}
Edit:
There still seems to be some issues with calculating sinRoll, when AbsF(cosYaw) < AbsF(sinYaw)..
Edit2:
I recalculated it all, and fixed an error in the G++ compiler. Now it works.
I have been trying to do this for many hours now, but I can't get the right result :(
I have two vectors: forward (fx, fy, fz) and up (ux, uy, uz). They are perpendicular unit vectors represented with 3 fixed variables each. Together, they represent a view direction for the camera. What I want is to set the camera to view down the forward vector with up being the upwards direction for the camera.
To do that, I need to convert from those two vectors to the corresponding camera yaw, pitch and roll.
Anyone here who have had success with something like that?
Well, that depends I guess. If you have lots of other units that die a lot, you might not want "any unit", since the trigger would be called quite often.
In that scenario, it might be better to make a trigger for each team, and add events when you add units (requires custom script). Also, if you have a lot of actions, you might want to split it out into a function to avoid code duplication.
That is just an optimization.. try the simple solution, if you run into performance issues regarding that trigger running too often, this would solve it.
To block communication, you can hide the message log button, and move the chat frame out of screen. Then you would have to make your own chat system to allow players to communicate. The down side is that players wouldn't receive whispers from outside the game anymore.
What I have created there is a static array of classes.
I assume you are getting the error that you can only make dynamic instansiations of classes. That means that every time you want an instance of c_Dialog, you have to call new c_Dialog(...). Consequently, if you want a variable of type c_Dialog, it has to be a pointer to it (c_Dialog* var). This is because for normal structs in galaxy, just typing c_Dialog var; actually allocates the instance in memory at runtime, but you can't get a pointer to that instance.
If you want to be able to just write c_Dialog[4] c_Dialog_RaceDialog; you should make c_Dialog a struct rather than a class. Just don't pass them around to functions too much, since that might be a bit expensive.
What I do is create a dialog button on the top left displaying the current buffs a player has. (Which is determined by triggers are not actual behaviors)
Still, behaviors might be more elegant, since that's the way buffs are supposed to work.
I'm probably gonna run into another problem with displaying the duration of the buff without causing a slowdown in the game.
A way to do that could be to just invalidate the buff bars every 1 second or every 0.5 seconds. Then you don't need to worry about when buffs are gained/lost. As long as you are happy with durations being in seconds, I don't think it will cause much lag.
The way I see it, you would need a data structure that lets you map from units to some records that specify what buffs are active.
You could make an array of records, and assign a custom value to units specifying an index in that array. By default, the custom value is 0, so it might be good to keep 0 as a "null pointer" (to indicate that no buffs are active).
Also, to make the system work for any number of units, you might want to make the array based on the data table rather than a regular array. That also makes index management easier (no need to reuse old indices). On the downside, the data table is slower than a global array, but I believe it's worth it unless you have a known small lower bound on the number of possible targets.
Based on that data structure, you can make algorithms to efficiently add and remove buffs, and to efficiently get buffs of a unit.
When adding a buff, get the custom value of the unit, if it is 0, then assign a new unused one, update the corresponding record, and update the buff frames for players targeting that unit.
When removing a buff, get the custom value, update the record, if no buffs are set, clear the record and set the custom value to 0, and finally update buff frames.
Getting the buff record when targeting a unit is just get the custom value, if 0, no buffs are present, otherwise get the record from the array.
It's written in sablecc, and based on a java compiler I wrote for a school project, which is why there are a few references to java in the naming.
The tokens are listed in the order of precedence. Helpers are not tokens.
I treat all variable types as identifiers in the parser, so you will not find the galaxy variable types among the tokens.
Also, except for the function string Galaxy_pp_Deobfuscate(string s), all functions added by the compiler are given a unique name (renamed in case of collisions).
You got all the numbers when you started from 1, so I guess they just decided not to index it from 0. That makes it more intuitive for people who are not used to programming.
About the order. I believe the data table is implemented as a hash map. This means that the text you give them are hashed to some integer. That integer should be seemingly random, and collisions should be rare (a collision are two strings that hash to the same thing). This means that whatever keys you add to the data table, don't expect them to have any logical order when read out like you do. When you ask for the name of the i't key, they just transverse the hash table and output the i'th key they come across (again, it's not sorted, just "randomly" ordered).
The benefit of a hash table is that when you ask for the value in a specific key "foo", they just have to hash "foo", and look at that entry of the hash table, which is pretty fast. When you add stuff to a hash map, you also just hash the string and insert at that index in the hash table (which is probably just an array).
Of course, I don't work at blizzard, so any comments about their implementation is purely speculation on my part, but it would make sense if that's how they implemented it.
When you post code to the forums, do it in <code>...</code> tags.
0
Yeah, I agree - it should do implicit casts in method calls.. which it now does :)
Edit:
@Mexaprone: Go
Folders are gray unless there is an enabled file in them.. When they are empty, they aren't really used in the compilation process. Enabling/disabling a folder just applies the setting to all files in the folder, so doing it on an empty folder doesn't really do anything - I could make it impossible.
0
The reason for the spaces afterwards is that the component I'm using for the treeview messes up the with of nodes when they are bold. The with is still calculated as if the text wasn't bold. So it's either spaces after the bold text, or having the text cut off because the node is too short - try making a really long project name to see what I mean (like abcdefghijklmnopqrstuvwxyz).
When you experience inconsistent enabled states, are you by any chance moving the program to another place on the harddisk, or renaming the project?
0
Yeah, should be fixed now.. Visual studio was an asshole an destroyed some of my main form - sorry for the wait.
0
1) I shall fix that!
2)
3)
PS stuff: I guess my screen is so big that it doesn't bother me that the object browser takes up space. I'll make it optional.
Edit:
How are things going with that dialog system?
0
Yes.. that would be the simple way to do it :)
The only down side is that such a trigger would execute each time any unit dies. But if you don't have too many threads due to sudden unit deaths, then it's probably not a problem.
0
Events are registered when the map loads. At that time, your initialization trigger has not yet run, so your array is not initialized. As a result, you'r not registering the correct unit. The only way to go around that is to add a piece of custom script code that adds the event from your initilization trigger
If that map initialization trigger is located in a library, it is a little more difficult, since I don't think you will be able to refer to the defeat trigger from there, unless it is also in the same library. If it's outside, make an initialization trigger outside the library, and put the custom script there - events for library triggers are registered before events for non library triggers, so they should run in the proper order.
If your overseer variable is in the library, then the name of the variable changes a bit. Maybe it will be lib1_gv_overseer.. If not, you will have to look for the right name in the custom script code for your library (ctrl+F11).
0
6 hours and lots of tests later, I got something that seems like it works.
In case anyone else could use it..
Edit:
There still seems to be some issues with calculating sinRoll, when AbsF(cosYaw) < AbsF(sinYaw)..
Edit2:
I recalculated it all, and fixed an error in the G
++compiler. Now it works.0
I have been trying to do this for many hours now, but I can't get the right result :(
I have two vectors: forward (fx, fy, fz) and up (ux, uy, uz). They are perpendicular unit vectors represented with 3 fixed variables each. Together, they represent a view direction for the camera. What I want is to set the camera to view down the forward vector with up being the upwards direction for the camera.
To do that, I need to convert from those two vectors to the corresponding camera yaw, pitch and roll.
Anyone here who have had success with something like that?
0
Well, that depends I guess. If you have lots of other units that die a lot, you might not want "any unit", since the trigger would be called quite often.
In that scenario, it might be better to make a trigger for each team, and add events when you add units (requires custom script). Also, if you have a lot of actions, you might want to split it out into a function to avoid code duplication.
That is just an optimization.. try the simple solution, if you run into performance issues regarding that trigger running too often, this would solve it.
To block communication, you can hide the message log button, and move the chat frame out of screen. Then you would have to make your own chat system to allow players to communicate. The down side is that players wouldn't receive whispers from outside the game anymore.
See this about moving the chat frame out
http://www.sc2mapster.com/forums/resources/tutorials/20323-ui-sc2layout-files-override-method-aiurchef-method/#posts
0
What I have created there is a static array of classes.
I assume you are getting the error that you can only make dynamic instansiations of classes. That means that every time you want an instance of c_Dialog, you have to call new c_Dialog(...). Consequently, if you want a variable of type c_Dialog, it has to be a pointer to it (c_Dialog* var). This is because for normal structs in galaxy, just typing c_Dialog var; actually allocates the instance in memory at runtime, but you can't get a pointer to that instance.
If you want to be able to just write c_Dialog[4] c_Dialog_RaceDialog; you should make c_Dialog a struct rather than a class. Just don't pass them around to functions too much, since that might be a bit expensive.
0
@Zolstice: Go
Well.. he did say that the buffs were not actual behaviors, but purely trigger based.
Still, behaviors might be more elegant, since that's the way buffs are supposed to work.
A way to do that could be to just invalidate the buff bars every 1 second or every 0.5 seconds. Then you don't need to worry about when buffs are gained/lost. As long as you are happy with durations being in seconds, I don't think it will cause much lag.
0
You are forgetting to create each element of the array.
There is really no need for a dynamic array if you always use the same constant size.
Edit:
Unless of course you plan to pass the array to other functions.
0
The way I see it, you would need a data structure that lets you map from units to some records that specify what buffs are active.
You could make an array of records, and assign a custom value to units specifying an index in that array. By default, the custom value is 0, so it might be good to keep 0 as a "null pointer" (to indicate that no buffs are active).
Also, to make the system work for any number of units, you might want to make the array based on the data table rather than a regular array. That also makes index management easier (no need to reuse old indices). On the downside, the data table is slower than a global array, but I believe it's worth it unless you have a known small lower bound on the number of possible targets.
Based on that data structure, you can make algorithms to efficiently add and remove buffs, and to efficiently get buffs of a unit.
When adding a buff, get the custom value of the unit, if it is 0, then assign a new unused one, update the corresponding record, and update the buff frames for players targeting that unit.
When removing a buff, get the custom value, update the record, if no buffs are set, clear the record and set the custom value to 0, and finally update buff frames.
Getting the buff record when targeting a unit is just get the custom value, if 0, no buffs are present, otherwise get the record from the array.
0
For a full and precise list of tokens for parsers, I think it would be easiest if I just give you that part of my parser.
http://www.sc2mapster.com/paste/4094/
It's written in sablecc, and based on a java compiler I wrote for a school project, which is why there are a few references to java in the naming.
The tokens are listed in the order of precedence. Helpers are not tokens.
I treat all variable types as identifiers in the parser, so you will not find the galaxy variable types among the tokens.
Also, except for the function
string Galaxy_pp_Deobfuscate(string s), all functions added by the compiler are given a unique name (renamed in case of collisions).0
You got all the numbers when you started from 1, so I guess they just decided not to index it from 0. That makes it more intuitive for people who are not used to programming.
About the order. I believe the data table is implemented as a hash map. This means that the text you give them are hashed to some integer. That integer should be seemingly random, and collisions should be rare (a collision are two strings that hash to the same thing). This means that whatever keys you add to the data table, don't expect them to have any logical order when read out like you do. When you ask for the name of the i't key, they just transverse the hash table and output the i'th key they come across (again, it's not sorted, just "randomly" ordered).
The benefit of a hash table is that when you ask for the value in a specific key "foo", they just have to hash "foo", and look at that entry of the hash table, which is pretty fast. When you add stuff to a hash map, you also just hash the string and insert at that index in the hash table (which is probably just an array).
Of course, I don't work at blizzard, so any comments about their implementation is purely speculation on my part, but it would make sense if that's how they implemented it.
When you post code to the forums, do it in
<code>...</code>tags.