What is your preferred language for developing Warcraft III maps?

[IcemanBo]

Not sure we understood each other, as I said it doesn't make sense to go fully away from GUI in first place, so finaly I also won't "go back". It's just part of possibilities I use.

 

[NoctissOHC24_omni]

i would say basic Jass / vJass but mostly GUI because i have to say that Blizzard has created such a wonderful and rich editor (srsly how is this a 16 year old game) that the GUI can really do most of the stuff you need, so you rarely relly on Coding (ofc im talking mostly custom campaigns and adventure maps, not insane shit like FOCS or DoTA)

 

[Xarwin]

I wanted to go back into creating maps, with some coding. I have no idea what to choose whateverso.
Wurst looked nice.

 

[Kaijyuu]

User friendliness is no small concern, remember. Wc3 mapping wouldn't be where it is today without GUI.

Sometimes it's hard for experienced creators to realize the importance of accessibility to new creators.

 

[Sapprine]

I dont program, im just a terrainer/artist and photoshopper.


Warcraft 3 for life/

 

[pusha1999]

Nani?!

just a mouse...little mouse

 

[emperor_d3st]

I'm using JASS, but only because I'm an oldtimer living in the past, still using 1.26 with JNGP. Quite frankly, I have too little time to investigate all the languages for Warcraft III and weigh the pros and cons. I estimate it would take hundreds of hours to make an educated decision.

I would rather use that on making maps in JASS.

That being said, I'm probably going to give vJASS a go.

For really simple triggers / algorithms sometimes I just use GUI.

 

[emperor_d3st]

The ideal solution would be a programming IDE, where you have a context-sensitive GUI suggestion when typing something. Just like how I choose "Unit" in the GUI, then move on to choose, "Create Unit Facing Angle" it is convenient when an IDE provides the ability for me to type the letter "u", it suggests "unit", then I type the ".c", and it suggests "create", so that I result in coding:

Jass NewGen Pack for 1.26 does what you describe - if I understood your point correctly.

I wholeheartedly agree, that it is a MUST to have an "autocomplete" / "suggestion" feature. As well as a complete function list.

In fact, when I'm calling my own custom functions, it's a real pain in the ass to remember all the parameters in the correct order, as well as the proper name of my function. (And in some of my maps I have over a hundred of these)
So it would be nice if the Editor "remembered" your custom functions in these autocomplete / suggestion / function list modules.

 

[Xisthename]

I would like to see more or less pure java as in android programming

 

[n00b]

GUI pleb reporting in

 

[Chaosy]

I would like to see more or less pure java as in android programming

Try Zinc, it has some aspects.

 

[ArOn]

I vote for GUI and i like it a lot.

 

[-Manuel-]

GUI is very tedius, the clicks sounds make me crazy, jass and vjass are my favorite options, the sound of keyboard keys is opera for me .

 

[Bribe]

GUI is very tedius, the clicks sounds make me crazy, jass and vjass are my favorite options, the sound of keyboard keys is opera for me .

GUI in moderation is extremely good though. I much prefer being able to select unit and ability visually rather than through rawcodes. Same with accessing preplaced units - you can't make gg_unit_hfoo_0001 (gg == game generated, aka preplaced) without GUI.

 

[-Manuel-]

GUI in moderation is extremely good though. I much prefer being able to select unit and ability visually rather than through rawcodes. Same with accessing preplaced units - you can't make gg_unit_hfoo_0001 (gg == game generated, aka preplaced) without GUI.

Yes, GUI has these features that jass does not have, I think all the moders started with GUI and thought it is a creation of the Gods (including me), but GUI is not comfortable to work with. The arithmetic is a pain in the ass, obviously if you combine jass and gui through Custom Script it is a bit better.

 

[Bribe]

Yes, GUI has these features that jass does not have, I think all the moders started with GUI and thought it is a creation of the Gods (including me), but GUI is not comfortable to work with. The arithmetic is a pain in the ass, obviously if you combine jass and gui through Custom Script it is a bit better.

Yeah you won't find anyone talking about what a joy it is to concatenate strings or do arithmatic in GUI. It's so horrible.

 

[Glint]

Yeah you won't find anyone talking about what a joy it is to concatenate strings or do arithmatic in GUI. It's so horrible.

I think that problem could be solved with something like this:

Spoiler

 

[Mirage1]

I voted for GUI as it is my preferred way to trigger and vJass for all its potential and to allow projects and resources which use it to be up to date with the lastest game patch. Also for simplicity of using only vanilla WE (if vJass is integrated). I think that @Bribe's vision sounds pretty good with a hybrid between GUI and vJass. However as @Kyrbi0 mentioned before there is some things that could be done about the object editor. After about ten years lurking here in Hive (even before I registered an account) I've download almost all kinds of systems and codes people made. And I few a need to say that the interaction between Object Editor and Trigger Editor could be way better than it is now. So I'm going to leave here a few hints of what I've saw and if that is of your interest unhide the spoilers bellow:

Unit Editor

Every data field of a unit should be accessible by trigger from shadow model and shadow size to minimum attack range and gold/lumber cost. The majority of fields doesn't interact with Trigger Editor and some of them are very important such as: attack range, minimum attack range, attack/defense type, projectile (why can't I have bounce and lightning(missile/splash) as weapon type instead of being one or the other this doesn't makes any sense), also there could be a field where instead of a missile the unit would cast a spell as an attack (C'mon who never wanted that as a data field in object editor?), resource cost, repair cost, bounty granted, train time, repair time, projectile arc, attack AoE, targets allowed, turn rate (in this case allow it to go beyond 1 for sake of instant turn), also stock fields, regeneration and sight. All those (except by Turn Rate) can't be detected nor set by triggers without having crazy ideas about how to do it with triggered-systems. Creating thoses detection methods can be generally funny but think again: those things are the very basics. They should be available by default. Two other things you blizz guys could provide are: Cone-Shaped Sight (a lot of stealth lovers will hail you if you create that (use a boolean to turn it on in a data field) and second something a lot of ppl would like too: allow the user to customize Unit Classification as a String instead of checkboxes and allow the trigger editor to read it as Strings too instead of Booleans. That would allow unlimited Classifications.

Item Editor

Also here gold/lumber cost should be available for both set and read in Trigger Editor. Stacking should be a boolean checkbox with a max stack field right bellow. We could be able to edit Stock Fields by triggers as well and please consider inserting Valid Target for Transformation and Perishable inside Trigger Editor in the Items section. I'm pretty much sure people will find use for them as detectors of some characteristic of certain items. And last but not least: allow items to have more than 5 functional abilities.

Trigger Editor

A few hints and questions I made to myself:
- Why we cannot detect when an attack is successful?(we can only detect when a unit begins to attack)
- Why there are more Specific Unit Events than Generic Unit Events when almost the totality of triggers needs to use generic units? Also Generic Unit can easily become Specific Unit through conditions.
- Why there is a damage detection system inside WE which is not available in Generic Unit Event? Allowing it to work in generic events and to detect not only spell and physical damage but also Attack, Damage and Armor Type would be a great addition to WE in general. Also detecting Healing without further conditions other than a single boolean would be nice.
- Region/Range/Life&Mana events could also be Generic Unit Events. In the case of regions we could say which region has been entered/left in conditions. In the case of range we could use a specific unit to call in conditions (e.g.: Approached Unit) as the triggering unit will be the one which is approaching.
- Allowing to more easily handle terrain type in Trigger Editor. We can change terrain type but we can't easily restore it to what it was before (e.g.: as the winter comes to an end we should see snow no more. Now it's lumpy grass, vines and leaves again) in a very similar way which Zerg Blight only covers the terrain in SC2.
- Add functions allowing us to create and manipulate item tables and (why not?) random groups in Trigger Editor. Those options can only used under Advanced tab and cannot be manipulated later by triggers.
- Consider adding some knockback actions. (There are hundreds of knockback systems here in hive. Ppl want it. Make it vanilla so we don't need to import anything. That's not a priority anyway if it's a bit too much.)
- Why researched upgrades can't be downgraded by triggers?
- Lastly but not least add more actions to Destructibles (e.g.:SetZheight) and Custom Value for them too. Also create Generic Destructible Events. Currently destructible events are kinda limited to use. (I ever wondered why we can't manipulate doodads with triggers)

I've pointed here a lot of things which people tries to create with triggers. You may notice that I gave some neat ideas but most of them are simple stuff which should be already there such as gold cost and train time (read and set). If the interaction between Object and Trigger Editor improves in a similar way I've said not only GUI triggering (my favorite) will be improved, but other languages as well. GUI is clearly the most preferred way to trigger so its GUI what you guys should improve. But I'm my opinion you should integrate vJass to WE before that.

 

[Kyrbi0]

I had no idea that GUI would be so overwhelmingly voted-for. I honestly thought I was in the minority as a GUIer. :O

Also, I'm very gratified people agree with my horrifying "Object Editor Coding" suggestion. xD

...and second something a lot of ppl would like too: allow the user to customize Unit Classification as a String instead of checkboxes and allow the trigger editor to read it as Strings too instead of Booleans. That would allow unlimited Classifications.

Oh my GOODNESS. This So Hard. I completely forgot about that, but it was be so supremely useful in so many ways; so many interesting & unique spells can only be made by abusing Classification categories.

Heck, even if that is too hard, at least open them all up a bit more for use; stuff like "Giant" is otherwise just taking up space.

- Why there are more Specific Unit Events than Generic Unit Events when almost the totality of triggers needs to use generic units? Also Generic Unit can easily become Specific Unit through conditions.
- Why there is a damage detection system inside WE which is not available in Generic Unit Event? Allowing it to work in generic events and to detect not only spell and physical damage but also Attack, Damage and Armor Type would be a great addition to WE in general. Also detecting Healing without further conditions other than a single boolean would be nice.
- Region/Range/Life&Mana events could also be Generic Unit Events. In the case of regions we could say which region has been entered/left in conditions. In the case of range we could use a specific unit to call in conditions (e.g.: Approached Unit) as the triggering unit will be the one which is approaching.

Oh wow, all of these, too.

 

[StormKnight]

voting for GUI

Knowing everything in the object editor.
Abilities
And Buff's
With triggers.

It just Makes my day.

Also I have to agree with everything Kyrbi0 said and quoted.

 

[chobibo]

"I had no idea that GUI would be so overwhelmingly voted-for. I honestly thought I was in the minority as a GUIer."

I always thought that GUI was the mostly used method of map modding since it was easy to get into. Thing is, when you use GUI, you also use jass without knowing it.

vrJass is new to me though, what is that?

 

[Chaosy]

WIP by Rufus I believe

 

[Loner-Magixxar]

I don't see the need for anything except GUI for even making the most complex systems and maps. I've never encountered any obstacles making whatever I imagine in my head using GUI. Although some custom scripts for leak prevention or unit indexing or other things can enhance it extraordinarily, but most of my coding happens in GUI.

On the side note:
Using GUI made me familiar with the concept of coding and then when I learned C# I found it very easy to grasp. It was like reviewing something from the past.

 

[Kadakash]

Just update the GUI system.
More options, dunno.

 

[Chaosy]

Just because it is possible does not mean it is good.

 

[emperor_d3st]

GUI in moderation is extremely good though. I much prefer being able to select unit and ability visually rather than through rawcodes. Same with accessing preplaced units - you can't make gg_unit_hfoo_0001 (gg == game generated, aka preplaced) without GUI.

True, true, but try to add a couple of numbers together in GUI, or godforbid a string. :S

I think the JASS writer of the World Editor could use a lot of polish.
For example, when I'm referencing an ability code in JASS, for example 'A001', it would be really nice if I was able to hover the mouse over it and confirm easily that it is indeed "My Special Critical Strike Ability". Same with unit types and whatever.

 

[pick-a-chew]

I primarily use GUI with some JASS on the side.

I had no idea that GUI would be so overwhelmingly voted-for.

It is not surprising if you think about it. Most mappers are novices which means GUI is the thing they'll be using to code their maps. Only people who are serious or invested in the World Editor will go on to use/learn other languages for coding. The major advantage GUI has is how accessible and easy it is to use. A 10 year old with only a mild interest in computers could produce something from it. Yet, at the same time, GUI does have some depth, meaning those novice mapmakers can go on to create "sophisticated" scripts that run to produce a quality custom game. I say "sophisticated" as GUI sometimes involves hacky solutions which people in the real world would probably point and laugh at.

Though it is curious that Blizzard are taking an interest in this topic. I hope they continue with 1.29's trend by adding to its functionality. More functionality means more options and potential solutions, which ultimately makes GUI better, simpler and easier to use (who knew such things were possible?!)

 

[~El]

Preface: My primary occupation is software engineering, not WC3 modding, so my view is a bit biased towards well-developed languages with good abstractions. Now, my choice:

Wurst, hands down.

Programming languages overall have a very long history, and this history shows that well-abstracted and well-designed languages prevail with time, because they allow you to focus on the problem and come up with beautiful, elegant solutions instead of having to work around the quirks of a language.

A good scripting language has to:
* Be easy to use
* Be decently abstracted
* Have minimal impedance when designing systems in it

JASS is anything but well-abstracted or well-designed. In fact, it's awful. It is extremely clunky and awkward, especially if you have a programming background in other languages.
* Unnecessary verbose, obnoxious syntax
* Virtually no support for any kind of abstractions
* No kind of macro/preprocessing/extension system natively
* No kind of dynamic allocation
* No kind of error handling
* Extremely slow compared to any modern scripting language
* And so on and so forth...

vJASS and Zinc, which are almost the same thing, just with different syntax, are a step up but still both extremely awkward languages that often get in your way rather than help you do what you want to do. Historically, they both are also very poorly designed with features that often conflict one another and are seldom used.

Most (not all) of the people I see responding here in favor of JASS/vJASS seem to be either part-time hobbyists or veterans who are just used to these languages and don't want to spend the time to learn Wurst. Others cite the presence of an established ecosystem of libraries and utilities which make it convenient to keep using those. This is perfectly fine, but objectively, this isn't due to the language, but rather just a side effect of how the WC3 community grew and matured over the years.

Wurst perfectly addresses all of those issues.
* Well-designed for its purpose
* Each feature has its purpose, no feature bloat
* Easy to learn and use, drawing inspiration from many modern programming languages
* Open source
* A proper compiler means that it is able to optimize the resulting JASS code much better than vJASS or Zinc could ever hope for
* Well-rounded and comprehensive standard library which covers 95% of common modding use-cases
* Support for programmatic object editing
* Lambda and closure support (this is IMMENSELY useful if you know how to use them effectively)
* Excellent, well thought-out toolchain which allows you to edit outside WorldEdit (which is a must if you want to store your source files in a git repository)

All of this combines into the simple fact that Wurst just lets you focus on the logic of your map, rather than getting bogged down in the verboseness and quirks of JASS or vJASS.

However, if Blizzard is considering adding support for a community language right in the editor, my personal opinion is that it's not such a great idea. Suggested alternatives:

* Introduce Lua. Lua is an amazing, feature-rich language that is extremely well-suited for scripting games. It has excellent performance even without LuaJIT, and with LuaJIT the code is usually on par with C/C++ speeds. It also has excellent coroutine support, which would be useful in implementing natives that 'pause' the 'thread', like TriggerWaitAction (or however it was called) and some others. It is also easy to transpile into, so with some elbow grease, Wurst could probably be reworked to use Lua as a backend and greatly benefit from it.

* Introduce some new, long-desired features directly in JASS, namely - dynamic allocation, structs, code references, etc. Focus on improving performance. That would greatly help transpiled languages like vJASS and Wurst, and is probably the easiest route.

* Extend the capabilities of WE and help the community provide better tooling in other ways, such as:
- Provide native command-line utilities for working with WC3 data formats, including BLP/MDX, Terrain, Object Data, Triggers, etc. GUI variants could be built on top of the command-line utilities, giving both regular users and toolmakers more options and more reliable tooling.
- Post open specifications of WC3 data formats and/or a library to work with them. The community has made great progress with some of that, but a lot of is it incomplete, buggy, or abandoned. Documentation is scarce and often incorrect. This is, arguably, the biggest challenge for anyone who's trying to create new tools for WC3.
- A plugin system for WE allowing to override/add new functionality to WE would greatly help everyone.

WC3 has an amazing and an extremely dedicated community, and it is only because of those brave souls who created and supported better and better tools for WC3, that this game is still alive. For almost the entire duration of WC3's existence, Blizzard failed to leverage that fact, and the community had to manage on its own. I think it's time to finally allow the community help Blizzard in resurrecting this game.

 

[maxxxus]

am i the only one who thinks each one of those languages are useful depending of what you're making in a wc3 map?

GUI is really simple to understand and it's cool for beginners.
JASS is very practical for those which want to develope a map more deeply.
VJASS, CJASS, WURST and rest could be very useful what people use them for.

i'd want to know why does every person here use some of those languages and tell me its benefits, and why don't use other languages to know why i should not use them.

i only know about GUI and JASS, but i've never learnt another programming language. so this is why i could not vote only for one language if i don't know how are the rest of them.

 

[~El]

am i the only one who thinks each one of those languages are useful depending of what you're making in a wc3 map?

GUI is really simple to understand and it's cool for beginners.
JASS is very practical for those which want to develope a map more deeply.
VJASS, CJASS, WURST and rest could be very useful what people use them for.

i'd want to know why does every person here use some of those languages and tell me its benefits, and why don't use other languages to know why i should not use them.

i only know about GUI and JASS, but i've never learnt another programming language. so this is why i could not vote only for one language if i don't know how are the rest of them.

It depends entirely on your background.

GUI is indeed an excellent tool for beginners, but people with background in programming will inevitably find it more clunky to use. Navigating UIs is always going to be slower than typing code in the comfort of your favourite IDE for any competent programmer. But, this discussions is mainly related to programming languages, and GUI is not a programming language per se. It's a visual programming tool.

If you really want to understand the perspective of those who bash JASS or vJASS, learn a modern language that is actively developed. It can be anything - Java, Kotlin, Python, JS, Lua, etc. Spend some time working in those languages. When you come back to JASS or vJASS, chances are, you're going to find that they are incredibly archaic and inconvenient compared to other modern languages.

I don't quite understand what you mean by "developing a map more deeply". If you're comparing JASS to GUI, then, yes, JASS gives you more options. vJASS goes one step further and gives you even more options which make writing code easier. By comparison, Wurst leaps miles ahead of anything else the WC3 community had before, and offers sleek, modern syntax, features, performance and more.

Seriously, try it. There's nothing you can do in JASS that you can't in Wurst. The only difference is that you're probably going to spend 5x times more time writing something in JASS than in Wurst. Time is a valuable commodity.

There's also another huge problem with JASS. A lot of the time, GUI users eventually hit some kind of wall or limitation in it (leaks, lack of some natives, etc. etc.), and ask for help. They get pointed to JASS.

But JASS is horrible. It makes writing code tedious, painful and error-prone. I can't imagine how many people looked at JASS, shook their heads, and said, "No, this is too uncomfortable. Programming is painful, I'll just stick to my guns." And then never look back. vJASS is only slightly better in that regard. Writing in JASS is boring, awkward, inconvenient, and often painful, and it leaves a wrong impression of what programming really should be - elegant, beautiful and satisfying.

Imagine if only we had a proper language like Lua instead of JASS? I can only begin to fathom how many more modders would've stayed, instead of leaving the scene out of frustration or boredom.

This is why almost everyone who tries Wurst switches to it entirely. It's good. Like, really really good. It is still hampered by many of the limitations of JASS, but Frotty and co. did an incredible job with what they had, and apart from a few rough edges it really feels like a modern language. And best of all, it teaches you skills and patterns that are easily transferable to other languages, it teaches you that programming can and should be fun, beautiful and pleasant.

That's why.

 

[Frotty]

I'm not sure what exactly you plan to do with this survey data, but if you want to extend the world editor in a fashion similar to WEX, I don't think Wurst should play a role there, because the main point of it is to get away from that clunky mess and use the world editor for terrain only.

As @Sir Moriarty already elaborated in detail, Wurst was made by developers, for developers. Pretty much all of us work in the IT industry and want a user experience close to that of a standalone language/framework - for Warcaft III. With Wurst and the related tools developed, we finally achieved complete independence from the game files and can make maps without them entirely.

Of course this is a niche. If you want your changes to benefit most map makers, focus on GUI and editor tooling. If, in the same process, features are exposed which can be used by wurst, that would be ideal imho.

 

[MyPad]

Is @Ruke still working on vrJASS?

 

[StormKnight]

[my second post]

depending ofc on what do you exactly have in mind for the map, Updating GUI can be much more beneficial for the future of modding in this community, first of all the statements that are risen that people who are not investing in (jass/vjass/wurst and other methods) just because they are not passionate enough to invest time in learning something can be very wrong in certain situations. for the most part however i have seen many people not getting into map making at all just because of GUI to begin with, let alone jass and wurst, so updating GUI can bring new people into modding as a whole.

not trying to hit people nor the community in the head AT ALL but the modding community (the actual people who sit down and make maps) is not very big and due to people not gaining anything from map making other then doing it for the love of the game, its hard for them to get into modding, learn GUI and decide if they want to move on to harder stuff or not or just drop out of the current idea's they have.

we've all been there, ditching ideas after another, and also since some people can't find time and just prefer to do it as a hobby.

unlike me, i'm one of the map makers that loves using GUI and is really passionate about what he can make for everyone to play, but investing time in learning it the hard way around in 2018 is not very comfortable for me, including when i have collage to attend to. but that's still me i have already started mapping for around 3 year's and started a project 1/5 year ago until now. but people who are trying to come into mapping if they are NEW and end up getting comfortable with GUI and if GUI happens to have more advancements it can really cover anything a map maker need's.

unless someone plans to start a huge project requiring 3 to 4 years worth of work GUI can pretty much handle this.

as for new things that can really impact map making and catapult the work of a lot of people i can say a small part for myself, i also found ( Mirage1's ) suggestions really useful, for me in person however: i have taken notice that with the help of ingame buff's one can really do marvel's in terms of adding new mechanics for abilities and even effecting other mechanics using abilities combined with buff's which can be used as one of the best detection system's for ability usage combined with auras.

adding functions such as [ buff is applied, buff expires, buff is dispelled, buff ends ]

or event: unit has a buff

can also really help us.

improving GUI can be much better in the long term as we would spend more time investing in making the things we love instead investing to learning how to make them to begin with for a longer term as learning GUI is easier and faster then other methods and it would appeal to newcomers when they see what can they do with it. and for those who say GUI is clunky and hard to maneuver in my personal opinion is not true at all and it even is more easy for me to copy paste my own work around my map's to increase the development rate of abilities, mechanics, functions and event's that fuel a map.

 

[maxxxus]

It depends entirely on your background.

GUI is indeed an excellent tool for beginners, but people with background in programming will inevitably find it more clunky to use. Navigating UIs is always going to be slower than typing code in the comfort of your favourite IDE for any competent programmer. But, this discussions is mainly related to programming languages, and GUI is not a programming language per se. It's a visual programming tool.

If you really want to understand the perspective of those who bash JASS or vJASS, learn a modern language that is actively developed. It can be anything - Java, Kotlin, Python, JS, Lua, etc. Spend some time working in those languages. When you come back to JASS or vJASS, chances are, you're going to find that they are incredibly archaic and inconvenient compared to other modern languages.

I don't quite understand what you mean by "developing a map more deeply". If you're comparing JASS to GUI, then, yes, JASS gives you more options. vJASS goes one step further and gives you even more options which make writing code easier. By comparison, Wurst leaps miles ahead of anything else the WC3 community had before, and offers sleek, modern syntax, features, performance and more.

Seriously, try it. There's nothing you can do in JASS that you can't in Wurst. The only difference is that you're probably going to spend 5x times more time writing something in JASS than in Wurst. Time is a valuable commodity.

There's also another huge problem with JASS. A lot of the time, GUI users eventually hit some kind of wall or limitation in it (leaks, lack of some natives, etc. etc.), and ask for help. They get pointed to JASS.

But JASS is horrible. It makes writing code tedious, painful and error-prone. I can't imagine how many people looked at JASS, shook their heads, and said, "No, this is too uncomfortable. Programming is painful, I'll just stick to my guns." And then never look back. vJASS is only slightly better in that regard. Writing in JASS is boring, awkward, inconvenient, and often painful, and it leaves a wrong impression of what programming really should be - elegant, beautiful and satisfying.

Imagine if only we had a proper language like Lua instead of JASS? I can only begin to fathom how many more modders would've stayed, instead of leaving the scene out of frustration or boredom.

This is why almost everyone who tries Wurst switches to it entirely. It's good. Like, really really good. It is still hampered by many of the limitations of JASS, but Frotty and co. did an incredible job with what they had, and apart from a few rough edges it really feels like a modern language. And best of all, it teaches you skills and patterns that are easily transferable to other languages, it teaches you that programming can and should be fun, beautiful and pleasant.

That's why.

ooh, thanks for explain your point. i think i'll learn more about wurst or lua; jass is really tedious and boring as you said. this is why i think we can't vote only for a language if you don't know how are the rest of them. i'd vote gui or jass just for being the only languages i know; wurst could be more cool than those.

 

[Ouguiya]

I made my original map with GUI and holy goofs, was it buggy! And slow (both to create, to debug and while running the map).

I recently got back into mapping and discovered Wurst and have been completely blown away. It's an amazing language. In my humble opinion, it is what JASS should have been like, with all the features offered by the VSCode integration. If you haven't tried it yet, @MindWorX , I can only recommend it. I am guessing that the number of users would be much higher if:

A - More people knew about it
B - More people knew about programming in general and
C - If something like this was already integrated.

Hence, my vote goes to Wurst, all the way. And the only thing I'm sad at is that I only have a single vote to give.

 

[Kaijyuu]

If we're even remotely considering having another inbuilt scripting language, my vote goes for Python. Then again, I'm a fanboy of that language, so

 

[Light]

If we're even remotely considering having another inbuilt scripting language, my vote goes for Python. Then again, I'm a fanboy of that language, so

It's the programming language I'm learning (I'd learn more about JASS's syntax, but learning Python is much better for me in the future), so I support!

 

[Bribe]

It's the programming language I'm learning (I'd learn more about JASS's syntax, but learning Python is much better for me in the future), so I support!

Then you guys would like Wurst (if not just for its indentation-based syntax).

 

[nnnnnnoT_T]

Wurst is pretty nice.

 

[yatyfornetreg]

wow, didn't expected the low penetration rate of Zinc.

Anyways, I found it's a bad idea if you try to invent a new language to the system. Human energy is limited.

JASS3? No please don't do that if there's a plan. I beg for that.

Things I think will benefit the community:

1. Fix the return bug of wc3 VM. Don't try to just fix it by changing the JASS compiler to fool us.

2. Add signature to the map. We certainly don't want our maps to be hacked and redistributed to the internet.

2.1. I know in the western world, people are more respectful to other people's hard work and creation. But it is not the case in China. There are a few G-arena-like platforms here and countless maps are stolen from one platform to another, by just - unzip the map - change a few models or texts or numeric values - zip the map - redistribute the map to another platform.

2.2. Believe it or not, Chinese community is probably the best reason why Blizzard still wants to update wc3 even that we have a dishonored history (it's safe to say more than 95% players and authors are using pirated version in China). After some non-Chinese (that's all I know) guys had hacked wc3 and enables external dll. In western community we've witnessed some wc3 map viruses and cool (but bad) stuff. But in China, some developers started to write dlls to --

enable IN-APP-PURCHASING in wc3 map.

After years, until 2017, the market grew to a reasonable enough scale that had drawn Blizzard's attention. Most of the new APIs you've seen in patch 1.29 was invented long ago by hacking the map (yes of course, using return bugs and external dlls). And Netease (Blizzard's current operator in China) had bundled things up. (read the post on HIVE's home page to understand it's not some child's play WC3 World Championship - Summer 2018).

To clear things up

- I'm not drinking alcohol while writing this post
- Netease is Blizzard's partner in China, it also runs WOW, Diablo 3, SC2, and rest of Blizzard games
- Netease had published a G-arena like platform in China, which allows players to use pirated version and yes Blizzard knows this. Of course this version is modified to enable external dlls

Here's a UI system. Pure native and screen overlay, no trackables, no stupid units model flying in a locked camera. This is what it is capable of:

(images from 魔兽地图编辑器吧-百度贴吧--中国人气最旺的魔兽3地图编辑讨论社区。)

Besides the UI system, there are things like:
- HTTP request
- Platform scoped Achievements, user profiles, etc..
- Guild system
and more.

2.3. Back to the story of other Chinese people being not respectful to other's work. Here's a new story. Around 7 years ago, a Chinese guy has localized JNGP and add some small gadgets - called it YDWE. After years of evolution, it is far more powerful than it was and became the de-facto standard tool in China. It is now maintained by Actboy168 and sumneko hosted on GitHub (actboy168/YDWE). Some of you might be familiar with Actboy168 because he's promoting his new optimizer in HIVE lately. Anyways, if you could read, you'll know that YDWE is published under Apache license.

However, Blizzard's partner in China, Netease, had used & modified the source code and then distributed it to the Chinese community (they just changed the version name for now, but I believe it will be something like "Netease Editor") without any copyright files and statements, i.e. disrespect Apache license. We don't have solid evidence that this is done by Netease but we'll keep watching this case. And Chinese law does not respect global software licensing neither, instead using another stupid and effectiveless system which I'll not discuss here.

2.4. Okay, that should be long enough for the background build-up. All I try to say is, there's a huge underworld out there and someone starts to make money from it in a dishonored way. Blizzard didn't care about this for a long time but now start to watch this just because money. I despise both of them.

2.5. Enabling digital signature would be a great way to prevent Netease to steal maps from the western communities. And it also brings confidence to pure map makers like me in China. Although it will not stop people in my country from using legacy version of wc3 but I think this by far is the best way to stop the loss.

3. Fix the known issues ASAP, like BlzSetItemExtendedTooltip.

4. Find better ways to support wurst. It's nice and brought us modern language features to write maps. Closures, intellisense (thanks to VS code), and so on.

 

[puffdragon]

Personally I use only JASS (jasscraft). The main reason is that, I didn't really trust 3rd party tools to be updated when there are changes to the game. But, Wurst style or LUA would be very nice to have. (tending a bit more towards Wurst but either would do).

Just PLEASE, for w/e changes, keep backward compatibility for old school users. (And for people like me that do not have able free time to be updated to such a radical changes in small amount of time)

Like make it option (as it is now kinda). JASS or Wurst syntax for example.

 

[yxq1122]

I choose Jass and cJass. Jass can be used to prevent compatible issues. The syntax of cJass is much closer to that of C/C++.

 

[sumneko]

I choose Lua, see actboy168/MoeHero

 

[The Panda]

I mean not every is smart enough for the JASS and VJASS I just use the regular triggers honestly.. but even those im not really good at either lol. I just wish they would make the trigger system much easier for beginners or people who want to make a map quick or whatever.

 

[OutsiderXE]

GUI! Everything else will just break at some point.

 

[BloodForBlood]

Why 60.3% GUI?

 

[Cokemonkey11]

In this post I hope to:

- explain why I use wurst
- guess why this thread exists
- make some observations based on those guesses
- extinguish some misunderstandings
- help us guess better in the future
- propose some good, practical options that blizzard might do to aide the modding community

This thread is about what the preferred language is for modding in wc3. My preferred language is wurst because:

- I'm still interested in wc3 modding but I'm the most time-limited that I've ever been. As previously mentioned, most wurst users are professional programmers or otherwise engineers. I only have about 8 hours a month to spend on wc3 modding these days, so I choose the most *efficient* environment/community to participate in. That's wurst by far.

A blizzard representative is asking this question for a reason, but not giving more details about why the survey exists. I think there are two reasons that might be:

- the usual blizzard way of keeping things a secret until they're finished (don't want to get users too excited, right?)
- statistically valid reasons - i.e. don't want to color/bias our resonses (I don't believe this is the case)

So I must guess that this thread exists because:

- Blizzard plans to allocate some resource towards maintaining/improving things for modders
- This survey is about understanding what developers will be affected, and how, by those changes; and how it could affect the greater community

So here are some guesses about how blizzard might do that...

- adding more GUI commands that implement "missing" function achievable only in JASS
- adding more JASS natives
- adding features to the world editor
- fixing existing bugs
- improving behavior/performance of GUI/JASS/existing natives/wc3 abilities
- improving things more generally, but "breaking" existing tooling (a-la 1.29)

Of these, I can think of some possible negative side-effects, against which blizzard must hedge their bets:

- leaving developers feeling underwhelmed/unimpressed by a wc3 update (new GUI commands that power-developers wont use)
- failing to lower the barrier-to-entry for beginner developers (adding new natives that mostly power-developers are interested in)
- failing to understand how productive developers defeat jank/writer's block/discovery (adding world-editor features that are only used by beginners)
- causing regressions or otherwise poor cost-to-benefit ratio when fixing bugs (casual users are unimpressed if you fix rare/niche bugs)
- fixing problems that only a subset of power developers care about (GUI and wurst users don't have to think about nulling locals, for example)
- disrupting power users so significantly that they don't come back (major game-breaking/changing updates that make e.g. a third-party compiler/preprocessor stop working)

With that in mind, I have some thoughts:

- The best changes are the ones that lower cost to entry, because in my experience, new developers are likely to find their own preferred development tooling, and it's actually hard to guess their past expertise. The wurst community has seen lots of completely new developers starting with wurst from scratch
- Not breaking vJass is worthwhile. Unlike wurst, the vjass tools are sort of black-box. There are no developers actively working on vJass tools, so if they break, lots of stuff breaks
- If you break our tools we mostly won't complain, but only if we know it will break in advance. "surprising" us with features is painful. Give us better visibility, like this
- adding new natives as done in 1.29 is awesome (when they work), and benefits both experienced developers and end-users of funmaps.


Onto misunderstandings:

Misunderstanding I: power developers don't like beginner developers/GUI users

It isn't true. Lots of us dislike reading/reviewing GUI triggers, but the vast majority of us started as children writing GUI triggers ourselves, and will happily help GUI users learn wurst (or vjass)

- See also carefully crafted scripts made just for beginners - Damage Engine 3.8.0.0

Misunderstanding II: everyone's opinion should be equal and hiveworkshop does/can represent wc3 modders fairly

For lots of reasons this isn't true. Only a select few users in this thread have used all 3 of GUI/vjass/wurst meaningfully, and another huge set of people aren't around today to participate in this thread.

- keep also in mind China, SE Asia, and Russians, who all have a different view of developer tooling
- we're all guessing why blizzard is asking this question/conducting this survey, and acting in our own interests
- We're too few to make useful statistical inferences. Our age, background experience, available time, etc are all hugely varying.
- even the very most experienced among us have blind-spots. @DracoL1ch and @TriggerHappy for example are (among) the only users here who have strong enough engine knowledge to make educated guesses about what's hard or easy to add in wc3 patches.

Misunderstanding III: vJass and wurst are pretty similar, but wurst is more like python

Wurst couldn't be more different than vjass or python, and users that draw conclusions about the first without substantial programming experience can't give useful opinions or feedback in threads like this.

Misunderstanding IV: if some modding tooling breaks, we're all affected equally

Not at all. Wurst still has numerous active tool developers that can and will circumvent breaking updates. vjass does not.

--

Guessing better in the future:

The only way for us in this community to give you better feedback is if we have more visibility into what blizzard is considering. That means:

- context is everything. To start with, what's this survey for? It's not even worth thinking about - just tell us.
- you can't rely on power developers to be contacting your representatives directly. As I alluded to before, some of us have magnitudes less time to spend on wc3 modding than we did in the past - but that doesn't mean our contribution to the community is insubstantial.
- fair and open dialog are totally necessary in any open community
- worrying that users will be sad if you don't deliver something (which was never commited to anyway!) is silly

--

Finally, here's what I think are some good, useful ideas for 1.30 - in the context of developer tooling

- An official (or blizzard-endorsed) one-stop introductory experience for new developers. This means documentation, executive summary, tutorials, etc for blizzard modding tools and things like paths, object ids, etc.
- official editor performance improvements (make GUI and object editor respond faster)
- modular editor subsystems (it would be great if I could launch a shared/official icon picker for world editor, from within vscode when writing wurst)
- official, sandboxed/secure natives for file and network IO
- platform stability (official linux client)

 

[Unryze]

I got used to pure Jass, but I do it in a very unusual way, I use notepad++ and code directly in war3map.j, so I can do whatever I want with it. Meaning i DO NOT use WE for script at all, only for making units/abilities, etc. I will demonstrate part of it, in case it will be bothersome I will remove it, so let's begin:

1. Ablility to customize Main function without any OP limits or confusion and even config.

I do know ExecuteFunc is slower, etc, but I dislike Call(), because it's logic is to literally put code from where you call it, however this makes me unable to use another ExecuteFunc normally, without causing threading problems, but I've never had problems with it.

And yes, I do not use InitBlizzard, I only use some globals from blizzard.j, so I don't need to declare them again.

2. Free of any limitation of WE / Compiler.

Yes, this means an external syntax check and manual labour, but working like this for like 4+ years made me just stick with it.

3. Ease of use / Transfer.

By working directly with "out" part of the code you get used to working with any maps code, meaning ultimately you get the ability to pick things from others and easily adapt them to yourself.

4. Time saving.

Some of you might say, that using pure Jass is in fact slower, I would argue. I can pop my code in MPQ Editor and instantly test the changes, or use external syntax check, so I don't need to load the whole map in WE, etc. As for systems I can adapt them from wherever I want and then optimize them to what I see fit.

There are many other points, but I don't want to take up too much space, all in all, this is by no means good for beginners / normal people, but for some people that are like me, this is certainly good.

Now as for things I would like to see as natives:

1. Change unit model with code: native SetUnitModel takes unit WhichUnit, string WhichModel returns nothing
2. Change unit HP/MP regen with code: native SetUnitHPRegen takes unit WhichUnit, real amount, real Rate <- same with MP.
3. Add possibility to edit UI, so we can add CUSTOM STATS or change the amount of abilities that fit in one line, you can see that in RenderEdge.

So far those are the things I would LOVE to see and would benefit a lot.

 

[yatyfornetreg]

I got used to pure Jass, but I do it in a very unusual way, I use notepad++ and code directly in war3map.j, so I can do whatever I want with it. Meaning i DO NOT use WE for script at all, only for making units/abilities, etc. I will demonstrate part of it, in case it will be bothersome I will remove it, so let's begin:

1. Ablility to customize Main function without any OP limits or confusion and even config.
View attachment 299828View attachment 299827 View attachment 299829
I do know ExecuteFunc is slower, etc, but I dislike Call(), because it's logic is to literally put code from where you call it, however this makes me unable to use another ExecuteFunc normally, without causing threading problems, but I've never had problems with it.

And yes, I do not use InitBlizzard, I only use some globals from blizzard.j, so I don't need to declare them again.

2. Free of any limitation of WE / Compiler.

Yes, this means an external syntax check and manual labour, but working like this for like 4+ years made me just stick with it.

3. Ease of use / Transfer.

By working directly with "out" part of the code you get used to working with any maps code, meaning ultimately you get the ability to pick things from others and easily adapt them to yourself.

4. Time saving.

Some of you might say, that using pure Jass is in fact slower, I would argue. I can pop my code in MPQ Editor and instantly test the changes, or use external syntax check, so I don't need to load the whole map in WE, etc. As for systems I can adapt them from wherever I want and then optimize them to what I see fit.

There are many other points, but I don't want to take up too much space, all in all, this is by no means good for beginners / normal people, but for some people that are like me, this is certainly good.

Now as for things I would like to see as natives:

1. Change unit model with code: native SetUnitModel takes unit WhichUnit, string WhichModel returns nothing
2. Change unit HP/MP regen with code: native SetUnitHPRegen takes unit WhichUnit, real amount, real Rate <- same with MP.
3. Add possibility to edit UI, so we can add CUSTOM STATS or change the amount of abilities that fit in one line, you can see that in RenderEdge.

So far those are the things I would LOVE to see and would benefit a lot.

Firstly I'll discuss on your 3 requests, and then I have a few different opinions on how you make maps, hope you are not mad on me.

1. Search for the "chaos" abilities and have try. A neat API is always good, but for now, chaos would do the most job without too much hassle.
2. If you are not happy with the default regens, you can set those in game contants. "Menu" -> "Advanced" -> "Gameplay Constants". If you already know that, but you just want to change the regen values at runtime. Just set those constants to 0 and code it on your own. It shouldn't be too hard since you already know how to code in JASS. Create a forever running Timer, and loop through all units in map every second and set their MP/HP based on some global variables.
3. That is not a easy job. Most of this functionality is done by injecting external dlls to wc3, i.e. it's not official. I believe they have more important bugs to fix right now. But I also wanted UI editing.

Hope that helps.

Now let's talk about how you make your map. I write this because I fear that newcomers would learn an inappropriate way to modding.

Directly editing war3map.j is just fine. But I might not be a preferable way in terms of Ease of use / Transfer / maintainability and Time Saving.

Again, I recommend newcomers NOT to learn to code JASS in such way.

1. It's not easy. To deal with thousands or tens of thousands of code (especially awful language like JASS, yes JASS is awful!) is never a easy job. You need to define sections of functionality by yourself and only you know about that. Modern programming languages introduces low coupling high cohesion and modularity. Why is that? Because it's better. Of course if you are familiar with procedural languages or low level programming. It's totally fine that you do it in such way.

2. Not sure what you mean by transfer. If you are bootstrapping your other maps with some common codes in your war3map.js, yes it's good, because you know what you are doing after all. But if you mean to share your code with others, at least I have not seen any one doing that.

3. Say you want to change a spell later. In a well implemented modern language, you just need to find the spell file, and update it. In the entire war3map.j, you have to perform a whole context search and modify those lines. And it has a higher chance to produce new bugs because there's no interfaces defined as clearly as how it's done in a modern language. Even in GUI you can easily target the spell trigger you want to modify, and you are very confident that by modifying that very piece of trigger, other trigger won't be affected for the most cases.

4. Time saving has different dimensions, if you are making a quick map. It could be faster. But for the long run, because of its low performance on portability and maintainability. The foreseeable time cost will be huge.

Again, if you (@Unryze) get used to code in this way, it is totally and absolutely fine.

But if you are reading this post and planning to port from GUI to JASS, I sincerely recommend you to learn wurst.

 

[Unryze]

Firstly I'll discuss on your 3 requests, and then I have a few different opinions on how you make maps, hope you are not mad on me.

1. Search for the "chaos" abilities and have try. A neat API is always good, but for now, chaos would do the most job without too much hassle.
2. If you are not happy with the default regens, you can set those in game contants. "Menu" -> "Advanced" -> "Gameplay Constants". If you already know that, but you just want to change the regen values at runtime. Just set those constants to 0 and code it on your own. It shouldn't be too hard since you already know how to code in JASS. Create a forever running Timer, and loop through all units in map every second and set their MP/HP based on some global variables.
3. That is not a easy job. Most of this functionality is done by injecting external dlls to wc3, i.e. it's not official. I believe they have more important bugs to fix right now. But I also wanted UI editing.

Hope that helps.

Now let's talk about how you make your map. I write this because I fear that newcomers would learn an inappropriate way to modding.

Directly editing war3map.j is just fine. But I might not be a preferable way in terms of Ease of use / Transfer / maintainability and Time Saving.

Again, I recommend newcomers NOT to learn to code JASS in such way.

1. It's not easy. To deal with thousands or tens of thousands of code (especially awful language like JASS, yes JASS is awful!) is never a easy job. You need to define sections of functionality by yourself and only you know about that. Modern programming languages introduces low coupling high cohesion and modularity. Why is that? Because it's better. Of course if you are familiar with procedural languages or low level programming. It's totally fine that you do it in such way.

2. Not sure what you mean by transfer. If you are bootstrapping your other maps with some common codes in your war3map.js, yes it's good, because you know what you are doing after all. But if you mean to share your code with others, at least I have not seen any one doing that.

3. Say you want to change a spell later. In a well implemented modern language, you just need to find the spell file, and update it. In the entire war3map.j, you have to perform a whole context search and modify those lines. And it has a higher chance to produce new bugs because there's no interfaces defined as clearly as how it's done in a modern language. Even in GUI you can easily target the spell trigger you want to modify, and you are very confident that by modifying that very piece of trigger, other trigger won't be affected for the most cases.

4. Time saving has different dimensions, if you are making a quick map. It could be faster. But for the long run, because of its low performance on portability and maintainability. The foreseeable time cost will be huge.

Again, if you (@Unryze) get used to code in this way, it is totally and absolutely fine.

But if you are reading this post and planning to port from GUI to JASS, I sincerely recommend you to learn wurst.

1. I don't think that works that way, but I will try, that does not seem like a bad idea (edit: it does not change model, it changes unit with unit, so it is not what I wanted, thanks regardless), however having a native is MUCH better and it won't take them that long, because Drakolich and Karaulov were able to do it with memhack.
2. Again, this will stress the processor for no real need, and yet again, this is possible with memhack, meaning it should be much easier for Blizzard to make this, as these constants are produced by either calculation of STR and basic regen.
3. Yes and no, some of it comes from the WC3 functionality itself, and only one dll, also it should no be a problem for them to add such dll, anyways, this one is not even close to mandatory, just a neat thing to have, but you are right it might be a bit way too much time consuming.

I never said my way is any good for newcomers, in fact I said it will be hard for them, I should have added I do not expect anyone to work in such way, as it is VERY hard as you just said in the beginning, quoting myself: "this is by no means good for beginners / normal people, but for some people that are like me, this is certainly good." meaning I do not expect anyone to work in such way, just if they would like to, it might be the way to go for them, which will be like 0.01% of WC3 mapmakers.

Now about the points you made, and yes they are fair, but I would like to comment on them.

1. In the beginning, yes, but for me (and yes I do work with C/C++/LUA/Java(oh god I hate it), etc. (some web languages, which I doubt many people care) and I still prefer Jass syntax, it just looks better to me, if you want I can provide some parts of my code to explain it further, which I do not mind.
2. I am sharing my code to those, who ask for a way to do things, although it is more local, aka people that know me, mostly, and my code is never obfuscated or "optimized" with any tool, so anyone can freely take it and I encourage others to do so, if they want.
3. Well, it depends on how you look at things, for example it takes me about 30 minutes to fully code a hero, with 6 spells, with 1 storing damage to empower all others, and things like that, what I mean is, it depends on experience and how you look at things. As I said, this way is outdated, but once mastered it won't be behind even current "modern ways".
4. On this one you are actually wrong, I hope I am not as rude as Frotty is, will explain why later as a small off-topic. As I use directly ONLY natives that mostly won't change, I make the map be supported fully wherever I want, and I can make my own functions around such natives.

Contains a bit of off-topic:
As for the WURST, sorry, but people like Frotty are the reason that I despise it, let me quote this "smart" person: "stubborn, stuck up, will you ever grow up?". You can like what you use, but promoting in the way he did and saying everything else sucks, did kinda rub on me, so I just ignored it altogether, but I would be glad if you could somehow teach this guy some manners, because he lacks them big-time.

I hope I did not offend you in any way, was trying to explain myself further, thanks for your feedback though o/