Best of the Wurst 4

In this fourth issue of our blog we look at wurstscript's start into 2018, and our roadmap. Once again we're excited to mention that users within our awesome community are getting involved and contribute to the wurst.

The theme for this months code snippet is unit testing in wurst.

WurstScript, or Wurst for short, aims to be a completely integrated wc3 modding solution, with a focus on higher level programming and IDE experience, without sacrificing efficiency of the generated map script.

Updates

• The

  runmap

  command now uses

  war3.exe

  if it is present, which can improve loading time. The game executable detection has also been improved.
• Removed obsolete temp file creation when handling MPQ files, which prevents permission problems on certain systems.
• Compiletime mocks added for

  force

  and

  gamecache

  , enabling them to be ued in object editing and unit tests.
• The compiletime implementation of

  StringHash

  now returns values identical to those at runtime, thanks to @LeP
• We merged many awesome pull requests for the standard library (#23, #25, #26, #27, #28, #30, #31, #33, #34, #35, #36, #37, #38, #41, #42)
  • Big thanks to @HappyTauren @Trokkin @Jampion @karlek @Krankx and @Chaosy
  • Special thanks to @Sir Moriarty for providing us with new and improved FileIO and Sync packages. The biggest PR we have merged so far! (Codeless Save/Load in Wurst)
• We have made some improvements to our continuous integration process, so standard library changes, and pull requests to it are more seamless and powerful.
• Wurst's underlying mpq library JMPQ has been updated to support pkware decompression and file-less data extraction.
• The Wc3libs have been updated as well, providing WTS support and Jass's

  StringHash

  implementation.

*Note*: The showcase is now official - you should submit your wurst maps for a chance in the spotlight!

2018 Roadmap

Our main goals for this year are:

• Enhance

  wurst.build

  and the setup tool to allow more complete and seamless map compilation. In detail:
  • Support configuring

    scenario

    and

    force

    options
    
  • Provide a seamles API for running external tools before or after map builds
    
  • Make the setup tools fully functional from the commandline
• Reach 100+ github repos to become a supported language on Github Linguist. We need you to publish your wurst repos on Github!
  
• Implement most Jass natives/types for compiletime. Mainly for unit-testing wc3-specific code.
  
• Refine, extend, and unit test the standard library.

Unit Testing in Warcraft 3

Preamble: The 'unit' in unit testing does not refer to wc3 units - rather, a unit is an individual piece of source code that is being tested.

Tests allow you to verify the behaviour of your code outside of warcraft 3 at compiletime. Instead of the game interpreting your generated Jass code, Wurst interprets it and can therefore assert correctness and find errors in code, before they happen in the game.

The major benefit of a unit test is that it can cover most imaginable behaviours, even those that rarely happens inside the game, easily, and without wasting time executing such behaviours inside the game.

One of the caveats of unit testing is that compiletime jass interpretation depends on the completeness and correctness of the wurst compiler that is performing the testing instead of the warcraft engine. Wurst does not implement every native, and since we don't know the inner workings of wc3, it can't emulate everything identically.

There are many benefits of unit testing overall, such as:

• Prove that your code does what it's supposed to do.
• Help you improve and understand your code through by to break it.
• Make big changes to your codebase and verify that everything still works.
• Inherently reduce the number of bugs.

The easiest units to test are the ones that don't include warcraft specific elements. Here are some condensed example unit tests for our data structures, arithmetics and string manipulation from the standard library.

Code (WurstScript):

@Test function testAdd()
    new HashList<int>..add(5).get(0).assertEquals(5)

@Test function linearVecTest()
    let v = linear(vec2(3,4), vec2(6,2), 0.5)
    v.x.assertEquals(4.5)
    v.y.assertEquals(3)

@Test function testJoin()
    new LinkedList<string>()..add("this")..add("is")..add("a")..add("string")
    .joinBy(" ").assertEquals("this is a string")
 

Writing Unit Tests

To make any function a test, just annotate it with

[USER=179970]@Test[/USER]

. All functions with this annotation will then be recognized by wurst. This doesn't limit the function in any way and it could theoretically still be used inside your code and not exclusivly as test, however that is not recommended.

A unit test consists of two parts - the execution of the to be tested code and an assertion, that compares the actual result with an expected value.
You can find the assert functions inside the

Wurstunit

package.

The most simple example is an arithmetic test, because we can easily find out the expected value. E.g.

Code (WurstScript):

@Test function example()
    let actual = (10 .squared()) * 6
    let expected = 600
    actual.assertEquals(expected)

As you can see, we calculate what we want to test and then assert that the value is what we expect it to be.

Running Unit Tests

In VScode, use F1 to open the task prompt and enter "run test" and choose one of the options.


You can see the result inside the Output tab.



And that's it! You are now a testing guru. We hope you enjoyed reading this, and we look forward to next month's blog post wherein we'll take a practical look at composing visually beautiful spells in wurst.

Today we are announcing two new Hosted Projects!
The Legends of Arkain Series & Island Troll Tribes!

Legends of Arkain is a singleplayer campaign series focusing on RTS elements with various factions waging war on each other. It is up to you, the player, to choose your side. Step forth! The great nations and personalities of Arkain await you.

[READ MORE]

Island Troll Tribes combines survival and PvP melee combat in a fight to the death for domination of the islands. Players can join together on teams of up to six players per tribe, or even go head to head. You need to fight for survival against the environment and enemy trolls while gathering resources to build up your strength.

[READ MORE]

* * *

This is my first post as a Community Manager. For those who don't know me, I have been on the Hive for years because of my deep love for Warcraft 3. Two years ago, I started mapping again and since then I have been coming here daily. As unexcepted as it was for me, I am really glad to have become part of the staff. I have been enjoying this community for years and it's time to give back. Let's have a great time together!
Yours truly,
Wareditor.

Best of the Wurst 3

Welcome to the third issue of our Wurstscript blog! And happy new year!

Background: Wurst is a compiled, higher level programming language that provides powerful tools and safety for an integrated development experience in wc3 modding.

The theme of this month's issue is "object-editing in wurstscript".

Updates

Due to increased usage of the Wurst Tools, several critical bugs have been found and addressed in the month of december. Make sure to download a fresh version of the setup tool and update your compiler as well as projects accordingly. We are also glad to have accepted several Pull Requests for the standard library, and are proud to present Wurstbin, a wurst pastebin. Wurst and tools also now found their final home at wurstlang.org.

Compiler

• A couple of severe dynamic dispatch bugs have been fixed
• The buildmap command doesn't output maps with corrupted header anymore
• More jass types and natives like units and groups have been implemented for compiletime
• Compiletime hashtables now more closely mimic wc3 hashtable behaviour
• Class array-members can now be initialized during instantiation
• ObjData .txt output now uses the cascade operator to chain calls
• Fixed cases where text highlight was off-by-one in vscode
• Improved unit test console output fidelity
• Packages ending with "Tests" are now ignored from suggestions
• Logs from all tools are now stored at ~/.wurst/logs

Standard Library

• We merged several user-created pull requests, namely fixing OnUnitEnterLeave #20 issues and replacing the broken sync packages #19. Big thanks to @Sir Moriarty and @Trokkin
  
• Along with the unit test improvements for the compiler the stdlib package, Wurstunit has also been refactored and Tests for groups and units have been added
  
• Added more group and map convience functions
• UnitIndexer is now more flexible and allows configuring which units to index and how to index them

Setup App

• The setup no longer crashes if its google network test doesn't respond with 200 OK
• Proper logging has been added and is saved to ~/.wurst/logs/setup.log
• Regressions regarding project updates have been fixed
• The wurst.build file is now recognized as yaml inside vscode

Introducing Wurstbin

An elegant and simple way to share your wurst and jass code snippets. No login required.
Check it out

ObjectEditing 101

WurstScript ships with a jass "interpreter", which can evaluate Jass code outside of wc3. This is usually done when compiling the project - hence we name the timeslot it occupies "compiletime". This is the opposite of running the map inside the game, which we refer to as "runtime".



You can mark any function to be executed at compiletime, by simply annotating it with .

@compiletime

. The only caveat of this is that you can only use jass natives that have been implemented for compiletime, and you only have access to resources from your script that have also been initialized at compiletime.

Let's look at a small example:

Unit Generation Example

Code (WurstScript):

import UnitObjEditing
@compiletime function createUnit()
    new UnitDefinition('xyz1', 'ewsp')
    ..setName("Wurst Generated Unit")

Here we create a new UnitDefinition based on Wisp, and assign a name for it. These objectdata-classes then get transformed into the approriate binary files, in this case war3map.w3u, which are retained for runtime. Wurst is perfectly capable of managing these assets alongide units defined in the normal object editor.

Retaining variables

You might want to generate values at compiletime and just keep the evaluated result to use at runtime. A very common usecase for this is generating IDs.
Let's enhance our example from above with an automatically generated id which is stored in a global:

Code (WurstScript):

import ObjectIdGenerator
constant MY_UNIT_ID = compiletime(UNIT_ID_GEN.next())

@compiletime function createUnit()
    new UnitDefinition(MY_UNIT_ID, 'ewsp')
    ..setName("Wurst Generated Unit")

The

UNIT_ID_GEN.next()

call refers to an

ObjectIdGenerator

object that generates only safe IDs inside a range that isn't used by standard units. As you can see, you have to wrap your expression with

compiletime()

for it to be evaluated and retained for runtime.

Ability generation best practises

When generating abilities one should avoid using

AbilityDefinition

directly - instead, one of its subclasses, e.g. the concrete

AbilityDefinitionFireBolt

for Fire Bolt. This way you don't need the original id and can use the functions of the concrete subclass to modify ability-specific fields.

Code (WurstScript):

import AbilityObjEditing
@compiletime function generateFireBolt()
    new AbilityDefinitionFireBolt(MY_FIREBOLT_ID)
        // This setter would not be available on
        // the base class [ljass]AbilityDefinition[/ljass].
        ..setDamage(1, 200)

For custom triggered hero spells,

channel

is frequently used. Take a look at the API provided by

ChannelAbilityPreset

:

Code (WurstScript):

import ChannelAbilityPreset
@compiletime function generateLeap()
    new ChannelAbilityPreset(MY_LEAP_ID, LEVELS, true)
        ..presetTargetTypes(Targettype.POINT)
        ..presetCooldown((int lvl) -> 30 - (level * 2))

Notice the

presetCooldown

call with the lambda expression. Next to normal setters, the standard library provides

preset*

functions that are either convenience wrappers or take closure parameters to fill multiple levels using only one call.

Hiveworkshop Wurst News

• @Frotty and @Cokemonkey11 are now approved code reviewers for Wurst on hive workshop.
  
• The setup app is now an approved resource in the tools section

As always, come and chat with us on IRC or post on this thread to provide us feedback for these monthy blog posts, as well as requesting what you want us to cover next.

GET YOUR SNACKS READY!

B2W Map Contest Cup! $100 prizepool

STREAM ENDED

Foggy is the winner of the B2W Map Contest Cup 1v1!

Back2Warcraft (Twitch.TV) | HIVE

Twitch

More information: Cup - Warcraft III 1on1 B2W Mapping Contest Cup #1 | ESL Play

Tell the guys at Back2Warcraft what you think about the melee maps created for this contest here: B2W Map Contest Cup - Feedback Thread • r/WC3

So remember we hosted that [$100 Prize Pool] Melee Mapping Contest - 1v1 ? Great! Because now it's time to see the maps in action! The goal was to create a competitive 1v1 melee map that excels in terrain, dynamic and creativity, but most importantly balance. Thanks to Back2Warcraft we are now proud to announce six maps that everyone will have chance to play and compete.

SIGN UP HERE

More information on ESL

Back2Warcraft will be streaming on Dec 20th 19:00 CET

Place Reward

• 1st 75€
  
  
• 2nd 25€

Warcraft III The Frozen Mapping Contest Cup

• Date: December 20, 19:00 CET
  
  
• Format: 1on1 Single Elimination
  
  
• Platform: W3arena, channel: ESL Cup
  
  
• Early rounds: Best of one
  
  
• Quarter and Semi: Best of three
  
  
• Finals: Best of five
  
  
• Race: Before the veto each player must declare the race
  
  
• Veto: Ban till best - of, pick remaining, player on the left start first

Map pool by HIVE WORKSHOP

You can download all the maps here!

• Thawing Snow
  
  
• Swamped Temple
  
  
• Fields of Ruin
  
  
• Irresistible Mind
  
  
• Outskirts Stroll_v1.0
  
  
• (4) Temple Field
  
  
• Violet Outpost