GUI Spells Discussion

[Daffa]

Yeah, a generic title gg.

Okay, direct to case with all seriousness.

I have been observing, within these 2 years I have seen modifying Conditional Blocks (setting the allowed targets) in GUI Spells have been very ridiculously annoying, especially those with LONG GUI Codes. Ones that run on Init are the main ones, having condition blocks spread over the main spell triggers (cast and loop) causing some difficulty to modify them.

So, Hivers, especially GUI Coders, I want your opinion.

Should we keep it or we add a new rule :

The Configuration Trigger must be executed from the spell cast/loop trigger as necessity, with pointers such as units being available.

 

[Chaosy]

he Configuration Trigger must be executed from the spell cast/loop trigger as necessity, with pointers such as units being available.

To be honest I don't even know what you mean.

 

[Ardenian]

I also struggle.
Do you mean trigger conditions ( like If in the If/Then/Else) should be configurable separately in the configuration trigger ?

Or do you mean there has to be a seperate configuration trigger ( I think it is optional at the moment, it is just not allowed to hardcode)

 

[Daffa]

To be honest I don't even know what you mean.

I'm sure GUI Coders encounter things like a big ITE somewhere in the mist of gigantic GUI Code which is annoying to find (which contains filter of which unit hit by the spell). This is the topic I'm discussing here.

I also struggle.
Do you mean trigger conditions ( like If in the If/Then/Else) should be configurable separately in the configuration trigger ?

Or do you mean there has to be a seperate configuration trigger ( I think it is optional at the moment, it is just not allowed to hardcode)

Same as Chaosy above.

I am thinking for either making a little Jass tricky way (which of course IS NOT A GOOD SOLUTION) or making dual config trigger (more GUI friendly, but personally, I hate the extra trigger D

Yes, at the moment it's optional, as we see almost every single GUI Spell has their Unit Filtering within the depths of loop trigger or cast trigger.

It's hard to explain it in simple way for me, ugh

 

[Bribe]

That's not possible in the same trigger without GUIJASS. They'll have to use the ExecuteFunc/endfunction trick if they want filters only at the top, since GUI can't call to custom functions.

However, they can separate those "pick all units" conditions into a separate trigger. Yay, more triggers to copy to a new map??

 

[Daffa]

They're still in the same folder, aren't they?

Though yeah, separate the conditions inside that block. And I have to agree it's GUI-JASS to get things in one trigger, UNLESS the Init trigger is called again and again, and we all know why not...

 

[Ardenian]

Hm, I understand.. I think it is too much, making it a rule. I mean, if someone adds a good documentation and you have a bit of experience with GUI, then you can easily filter the necessary ITE, if you are ready to spend one or another minute.

 

[Daffa]

Yeah, I see the point.
Guess there's no neccessity to add this then?
I don't say must, it can be optional recommendation.

 

[Zwiebelchen]

Great idea! Let's make GUI spells more convenient to use. No wait, that would be a JASS spell then...

Seriously, folks. If you complain about GUI being cumbersome, switch to JASS instead of applying band-aid.

 

[Ardenian]

I think it is a good idea, Daffa the Mage, if someone using GUI actually knows how to do what you suggest. But, as Zwiebelchen points out, it is more likely someone knowing how to do so is using JASS anyways.

 

[Bribe]

GUI is underestimated too often. While some things, like filters, concatenation and arithmetic are annoying to configure in GUI, other things are phenomenally better like selecting a unit, spell or buff type. You don't have to worry about syntax errors and you have a clearly-defined workspace with visible tools. There are some functions that are impossible in vJass like choosing a pre-placed unit (gg_unit_x won't generate unless you use that GUI feature).

More intricate things, such as creating abstract code (ie. Table) is very annoying in GUI. vJass has a purpose, but it is proliferated and encouraged more often than it needs to be. There is nothing wrong with a vJass script using a GUI Indexer or Damage system, but there are many vJass systems that would be too painful in GUI.

 

[Daffa]

Yeah, guess there's no need for these kinds of additional setups.