- Joined
- Jan 9, 2019
- Messages
- 102
GUIvJASS Basics ‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾ |
Preface |
GUI is nice to see and manage, but it's slower than JASS as everyone already knows. But having every single trigger written in JASS can cause creeping headaches for some. So, why not use them together? |
GUI's Limits | ||||||||||
We know that JASS can do all things there is, but it's not fully supported by the GUI, and as a matter of fact, GUI makes it perform worse. Then everyone knows that GUI is awesome. But, what exactly are GUI's limits compared to its better sibling?
|
The Environment | ||||||||||
With the current limitation of GUI, and how it usually works with temporal variables, this is the basic environment of a proper GvJ.
|
BasicGvJ - The Basic Library |
On top of the defined environment, GvJ must have a basic library for GvJ systems to refer. This is important to make sure those systems can properly check and use the correct temporal variables that GvJ environment has. This basic library must not be changed, but it can be extended, as in adding more udg temporal variables, and making more advanced/specific libraries related to GvJ environment.
JASS:
|
Textmacros As GUI API |
The title explains itself already, but why? Firstly, what textmacros do is just copy-pasting lines of codes which is done before anything else are processed. Due to this, textmacros won't make unnecessary extra function calls. Secondly, it makes GvJ systems easier to be implemented as both a vJASS system with the usual API and as a GvJ system with its textmacro API. Thirdly, it should be easier for GUI users to use GvJ systems with textmacro API, because there's only one syntax for executing textmacros and all textmacro arguments are always string constants. Lastly, textmacros are very very versatile that they can even be used to insert partial block statements. Though used simply to pass partial identifiers is huge enough, as can be seen in BasicGvJ library. |
Passing Arguments and Return Values |
There are some interesting facts about this if we're to use textmacros as GUI API. The first fact is that one single custom-script action will be very efficient in many aspects, including how the arguments are all pseudo-arguments. Another fact is that one textmacro run can return multiple values at once, returned as GUI-friendly temporal variables. And more, the arguments required by a textmacro API are "passed" by reference, increasing its versatility. With all of those in mind, here's an excerpt from a GvJ system plus a GUI example alongside it.
JASS:
As it can be seen, the use of the udg_ prefix is unavoidable. But actually, this is a good thing and should be the standard for passing udg variables. Experienced GUI users should've already known a little about this prefix, as it appears every time they're removing locations in call RemoveLocation(udg_Something) . So it shouldn't be too hard for them to grasp this. |
Other GUI API |
While there are different ways of making a good GUI API, other kinds of API shouldn't be regarded as GvJ API, even if those API work in a GvJ environment. This is because as the name itself implies, the API must be both GUI and vJASS at the same time. It is also for standardizing the definition of a GvJ API, which is always a textmacro statement. |
Conclusion |
This is more of a way to organize a map's scripts as it doesn't introduce anything new. Rather, it enforces rules to bridge the difference between JASS and GUI and to standardize a clearer work-environment for GUI. Also, it must be clear that this is not aimed for speed. If anyone wants speed, go with pure vJASS. |
Brought to you by Overfrost!
Attachments
Last edited: