[General] GUI triggering in 2023.

[Proxym8]

I apologize if this question is beating a dead horse, but would a map uploaded here be approved if it were solely composed of GUI triggers? I am well aware that vJASS is the superior method for creating all manner of custom things, but it also requires a decent amount of time to even get started, let alone begin making more creative stuff.

I ask this because WE GUI triggers have been greatly expanded since the time of 1.26a, and the Editor now offers a lot of functions within the GUI that were previously impossible (unless you were using vJASS) to achieve.

Would a map made with GUI even be possible? Are memory leaks avoidable this way, or is vJASS a must to ensure orderly triggers?

 

[Pyrogasm]

Nobody cares what you use to create your map. Everybody will care if your map runs inefficiently or egregiously leaks memory.

A full GUI map will be at a disadvantage in those regards but it is perfectly serviceable. Lua > vJASS > JASS > GUI. There are a few Lua resources that make memory leak management dead easy in GUI... but you do still have to do it. If you are not using such a resource you will stillhave to manually clean up your unused data yourself using functions not directly accessible in GUI.

I ask this because WE GUI triggers have been greatly expanded since the time of 1.26a, and the Editor now offers a lot of functions within the GUI that were previously impossible (unless you were using vJASS) to achieve.

This is not really true. There are a lot of new things that both have access to. There are a fairly small number of things now accessible to GUI that were only accessible to JASS around 1.26a.

 

[Remixer]

Yeah, the trigger language that you use does not matter as long as the triggering itself is of high quality. People tend to shy off from GUI because of its limitations (that used to be greater) and its slowness.

 

[Proxym8]

Nobody cares what you use to create your map. Everybody will care if your map runs inefficiently or egregiously leaks memory.

A full GUI map will be at a disadvantage in those regards but it is perfectly serviceable. Lua > vJASS > JASS > GUI. There are a few Lua resources that make memory leak management dead easy in GUI... but you do still have to do it. If you are not using such a resource you will stillhave to manually clean up your unused data yourself using functions not directly accessible in GUI.

This is not really true. There are a lot of new things that both have access to. There are a fairly small number of things now accessible to GUI that were only accessible to JASS around 1.26a.

So, if I understand you correctly, removing all memory leaks caused by GUI triggering is impossible with GUI?

 

[Remixer]

Removing all leaks is impossible, but you should remove those that you can.
Certain Blizzard natives leak no matter what, but in Jass you can use more functions and the natives that Blizzard functions are made of.
Take an example for moving a unit to the center of the map.
In GUI you would Move the unit to the location (center of the map), while under the GUI interface the game actually creates a location (Coordinates 0,0), thus leaking a "location" data, since that same "location" cannot be referenced anymore, thus you would need to remove that location handle (remove it from the memory). A lot of Blizzard natives have these datapoints that leak.
In that same example, if you used Jass, you would simply move the unit the coordinate 0,0, since you don't actually need to create a datapoint for the "location", the knowledge "0,0" is enough.

Now if you want to create that same example in GUI without leaking, you first need to create a Point variable (lets call it Point A). When you want to move the unit to the center of the map, you assign value to the Point A (Point A = 0,0). And move the unit to it, and after that you call function to destroy that location (it only destroys the instance of reference to the point A location).
More or less like that, someone can correct me if I'm horribly wrong.

 

[Proxym8]

Removing all leaks is impossible, but you should remove those that you can.
Certain Blizzard natives leak no matter what, but in Jass you can use more functions and the natives that Blizzard functions are made of.
Take an example for moving a unit to the center of the map.
In GUI you would Move the unit to the location (center of the map), while under the GUI interface the game actually creates a location (Coordinates 0,0), thus leaking a "location" data, since that same "location" cannot be referenced anymore, thus you would need to remove that location handle (remove it from the memory). A lot of Blizzard natives have these datapoints that leak.
In that same example, if you used Jass, you would simply move the unit the coordinate 0,0, since you don't actually need to create a datapoint for the "location", the knowledge "0,0" is enough.

Now if you want to create that same example in GUI without leaking, you first need to create a Point variable (lets call it Point A). When you want to move the unit to the center of the map, you assign value to the Point A (Point A = 0,0). And move the unit to it, and after that you call function to destroy that location (it only destroys the instance of reference to the point A location).
More or less like that, someone can correct me if I'm horribly wrong.

Ok, I get it. GUI simplifies a lot of things for the end-user by automatically creating hidden variables as needed, but it doesn't automatically 'clear' them after the fact. Yes?

 

[GIMLI_2]

You are perfectly fine with GUI if you use it right.
People are always talking about speed and how slow gui is compared to jass, and jass to lua. The reality is, if you know what you are doing, everything is viable. I never had any performance issues in any of my maps, even when using GUI.

 

[Chaosium]

Ultimately you're making a map for players, not modders. The average custom map enjoyer doesn't give a flip about what code you use as long as your map is fun and suffers from no performance/crash issues

 

[Nichilus]

One of the advantages of using lua or vjass compared to gui is the option to use local variables. Local variables are scoped to the called function (compared to global variables used in GUI, which are accessible by any function/trigger) - that means local variables can't have their value changed by accident by some other trigger. Also, since they exist only in the scope of the function, you can give them meaningful non-unique name - compared to global variables which are accessible from everywhere and thus have to have a unique name across the entire map.
So for example a local unit variable can be called 'sourceUnit' in multiple functions. If you wanted to do similar thing in GUI, you would have to usually use some prefix name like 'MyAbility_SourceUnit' and 'AnotherAbility_SourceUnit' - you then end up with a large list of global variables.

This isn't really a performance advantage, but it can keep your map cleaner

Edit: Also, you don't have to have an entire map/system only in vjass or only in gui - you can mix it as you need. For example in my map I needed to have a pathing check for one of my spells so I made the pathing check in vjass and the rest of the spell in GUI. The GUI then calls the vjass part for the pathing check.

 

[Uncle]

I worked with a friend of mine who was new to the Trigger Editor and still learning GUI. For our map we went with Lua as the Scripting Language, with more complex systems being coded by me in Lua and everything else done using GUI triggers. This worked great.

So there's no reason to limit yourself to one (GUI) or the other (coding), but you'll be perfectly fine sticking with just GUI. That being said, Lua is a must have and you're missing out on a huge list of improvements if you don't use it (imo). It will make your GUI triggers much easier to manage, especially with systems that Bribe and other users have created over the years that were designed specifically for GUI users.

As an example, here's a hybrid Lua + GUI trigger that will Create and Kill a Footman after a 1 frame delay:

• Example
  • Events
    • Time - Elapsed game time is 1.00 second
  • Conditions
  • Actions
    • Custom script: TimerStart(CreateTimer(), 0.00, false, function()
      • Unit - Create 1 Footman...
      • Unit - Kill (Last created unit)
      • Custom script: DestroyTimer(GetExpiredTimer())
    • Custom script: end)

I use this trigger as an example because this sort of thing would be overcomplicated in Jass requiring multiple triggers and other nonsense. And there are Lua systems that would make this even easier.

The only issue with Lua is that most systems and tutorials were made before Lua was a thing, so you may get confused when looking something up since it'll be using Jass syntax. It's usually a really easy adjustment though.

Some Lua systems designed for GUI users, the first one being a total game changer:

[Lua] - Lua-Infused GUI + Automatic Memory Leak prevention

Lua-Infused GUI + automatic memory leak handling Modernizing the Trigger Editor for a brighter future for GUI. This resource, among many things, converts locations, groups, rects, forces and even the GUI versions of Hashtables into Lua tables, making it so that you never have to remove them (as...

www.hiveworkshop.com

GUI Unit Event (now with a state-of-the-art Lua version)

Unit Event for GUI gives you access to all kinds of events which normal GUI events can't do: Function Lua vJass Subject unit of the event UnitEvent_unit UDexUnits[UDex] Event index (for use within an array). UnitEvent_index UDex Data attachment to unit Set UnitEvent_setKey = unit Set...

www.hiveworkshop.com

Damage Engine 5.A.0.0

GUI Damage Engine

www.hiveworkshop.com

 

[GIMLI_2]

I use this trigger as an example because this sort of thing would be overcomplicated in Jass requiring multiple triggers and other nonsense.

• trigger
  • Events
    • Time - Elapsed game time is 1.00 seconds
  • Conditions
  • Actions
    • Custom script: call ExecuteFunc("foo")
    • Custom script: endfunction
    • Custom script: function OnTimeout takes nothing returns nothing
    • Unit - Create 1 Footman for Player 1 (Red) at (Center of (Playable map area)) facing Default building facing degrees
    • Unit - Kill (Last created unit)
    • Custom script: call DestroyTimer(GetExpiredTimer())
    • Custom script: endfunction
    • Custom script: function foo takes nothing returns nothing
    • Custom script: call TimerStart(CreateTimer(), 0.00, false, function OnTimeout)

 

[Uncle]

• trigger
  • Events
    • Time - Elapsed game time is 1.00 seconds
  • Conditions
  • Actions
    • Custom script: call ExecuteFunc("foo")
    • Custom script: endfunction
    • Custom script: function OnTimeout takes nothing returns nothing
    • Unit - Create 1 Footman for Player 1 (Red) at (Center of (Playable map area)) facing Default building facing degrees
    • Unit - Kill (Last created unit)
    • Custom script: call DestroyTimer(GetExpiredTimer())
    • Custom script: endfunction
    • Custom script: function foo takes nothing returns nothing
    • Custom script: call TimerStart(CreateTimer(), 0.00, false, function OnTimeout)

That may not require multiple triggers but it might as well have. That's ridiculously overcomplicated compared to how simple it's in Lua. Plus far more limiting when dealing with local variables. I spit in the face of Jass!

 

[GIMLI_2]

Is it tho? It is one additional function call to get the order right.
Jokes aside, yes it is limiting (for GUI users) and it looks like shit.
But i never felt restricted when using (v)Jass. Sure, it sometimes takes less efficient workarounds to get stuff done, but it never seemed to have affected my map in a bad way.

 

[Uncle]

Is it tho? It is one additional function call to get the order right.
Jokes aside, yes it is limiting (for GUI users) and it looks like shit.
But i never felt restricted when using (v)Jass. Sure, it sometimes takes less efficient workarounds to get stuff done, but it never seemed to have affected my map in a bad way.

YES, it is! But yeah, it's not going to affect your map in a noticeable way that would deter people from playing it. But it will affect your enjoyment of the mapmaking process as it's really a night and day difference. I know a lot of people are so deep in Jass that it's tough to make the switch, but if you're a new user or have some free time on your hands then it's really worth it.

Every new user that comes to these forums is unaware of Lua and they have all sorts of problems that would be much easier to solve if they were on Lua mode. For example, they could be using Bribe's Lua-Infused GUI which removes the need to ever worry about setting and removing Point/Unit Group/Player Group variables ever again. I could finally stop giving people the speech about memory leaks. I could also stop offering janky workarounds like shadowing global variables in order to safely track data over time. Waits, the enemy of mankind, become precise and leak-free because they're now treated as Timers. So basically every "noob trap" goes away. Alas, it's tough to get them to use something they don't even know exists.

 

[GIMLI_2]

It will affect your enjoyment of the mapmaking process though

That is personal taste. I prefer jass syntax over lua syntax, it looks clearer to me and it is type safe. I wouldnt call myself deep into jass because i use c# almost every day, i just did not find a reason to switch to lua yet. I was able to do everything i want with jass so far.

It is true that you can improve the GUI experience a lot with the inclusion of lua code (especially with the ability to overwrite functions), that is obviously not possible with jass.

 

[Uncle]

That is personal taste. I prefer jass syntax over lua syntax, it looks clearer to me and it is type safe. I wouldnt call myself deep into jass because i use c# almost every day, i just did not find a reason to switch to lua yet. I was able to do everything i want with jass so far.

It is true that you can improve the GUI experience a lot with the inclusion of lua code (especially with the ability to overwrite functions), that is obviously not possible with jass.

Fair enough, if you like C# then maybe check this out: Home

 

[WilliamYoung]

Removing all leaks is impossible, but you should remove those that you can.
Certain Blizzard natives leak no matter what, but in Jass you can use more functions and the natives that Blizzard functions are made of.
Take an example for moving a unit to the center of the map.
In GUI you would Move the unit to the location (center of the map), while under the GUI interface the game actually creates a location (Coordinates 0,0), thus leaking a "location" data, since that same "location" cannot be referenced anymore, thus you would need to remove that location handle (remove it from the memory). A lot of Blizzard natives have these datapoints that leak.
In that same example, if you used Jass, you would simply move the unit the coordinate 0,0, since you don't actually need to create a datapoint for the "location", the knowledge "0,0" is enough.

Now if you want to create that same example in GUI without leaking, you first need to create a Point variable (lets call it Point A). When you want to move the unit to the center of the map, you assign value to the Point A (Point A = 0,0). And move the unit to it, and after that you call function to destroy that location (it only destroys the instance of reference to the point A location).
More or less like that, someone can correct me if I'm horribly wrong.

Thanks for the suggetion

 

[Uncle]

Thanks for the suggetion

Remixer is correct but I just wanted to add 1 little clarification, you don't need to reference Coordinates in GUI to prevent the leak with the Point A example. You can simply do this:

• Set Variable PointA = (Center of playable map area)
• Unit - Move (YourUnit) to PointA
• Custom script: call RemoveLocation(udg_PointA)

That will clean up the memory leak.


To understand better why it leaks in the first place:

Here's the code for getting the center of a Region. It's a little confusing because Blizzard used different terminology in their code:

function GetRectCenter takes rect whichRect returns location
    return Location(GetRectCenterX(whichRect), GetRectCenterY(whichRect))
endfunction

Rect = Region (basically, it's a little more complex than that but don't worry about it yet)
Location = Point

GetRectCenter is the name of the function. It's basically an Action but in code form. It requires that you give a Region (whichRect) when trying to use the function. By doing this it will create a new Point variable (Location) which is positioned at the center x coordinate (GetRectCenterX) and center y coordinate (GetRectCenterY) of the given Region. It then returns that Point variable to whatever function (Event/Condition/Action) that was trying to get the center of the Region. In other words, this function Sets a Point variable for you and then returns it to you for your own use.

However, there's an issue here. The Point (Location) variable that it creates for you never gets destroyed, therefore it will exist in the game's memory taking up space for no good reason. That's where you step in and use a Point variable yourself to intercept the returned data. You're basically telling the GetRectCenter() function that you want to keep track of the Point yourself, this way you can Remove it when you're done with it.

Note: I believe (Entire map) leaks so maybe don't use that one. You can always create your own Region that encompasses the "entire map" to avoid this issue.

 

[WilliamYoung]

Remixer is correct but I just wanted to add 1 little clarification, you don't need to reference Coordinates in GUI to prevent the leak with the Point A example. You can simply do this:

• Set Variable PointA = (Center of playable map area)
• Unit - Move (YourUnit) to PointA
• Custom script: call RemoveLocation(udg_PointA)

That will clean up the memory leak.


Here's the code for getting the center of a Region. It's a little confusing because Blizzard used different terminology in their code:

function GetRectCenter takes rect whichRect returns location
    return Location(GetRectCenterX(whichRect), GetRectCenterY(whichRect))
endfunction

Rect = Region (basically, it's a little more complex than that but don't worry about it yet)
Location = Point

GetRectCenter is the name of the function. It's basically an Action but in code form. It requires that you give a Region (whichRect) when trying to use the function. By doing this it will create a new Point variable (Location) which is positioned at the center x coordinate (GetRectCenterX) and center y coordinate (GetRectCenterY) of the given Region. It then returns that Point variable to whatever function (Event/Condition/Action) that was trying to get the center of the Region. In other words, it Sets a Point variable for you and then gives it to you for your own use.

However, there's an issue here. The Point (Location) variable that it creates for you never gets destroyed, therefore it will exist in the game's memory taking up space for no good reason. That's where you step in and use a Point variable yourself to intercept the returned data. You're basically telling the GetRectCenter() function that you want to keep track of the Point, this way you can Remove it when you're done with it.

Note: I believe (Entire map) leaks so maybe don't use that one. You can always create your own Region that encompasses the "entire map" to avoid this issue.


Ok, thanks. I will keep it in my mind. I was actually searching for this https://mbaessayhelp.com/mba-thesis-topics / website online because I am looking for the MBA thesis topics regarding my work and while searching for it online, I found your post.

Ok, thanks. I will keep it in my mind.