[Spell] [Wurst] Trying to make tutorial spell work

[xylon]

Hi, I'm new to the forum.

The question is very simple:
I copied all the code from WurstScript • Best of the Wurst 5 - Late March Update, however when I build the map the ability is created as intended (Conflagration spell under custom abilities) but no code is exported to the Editor.
Furthermore when I add the spell to blood mage and try to use it on some trolls, nothing happens (which is expected since no code is present in the Map).
Also no effect is created (I have noticed Art - Effect is null, as are other Art related fields).

Steps to reproduce:

1. Follow normal installation of Wurst as per the official instructions
2. In the default example map, copy the code given in bestofthewurst5 into 3 separate files in your wurst folder.
3. Build the map in VSCode
4. Into World Editor, no code is found. Art effects for Conflagration are missing. If you add the spell to Blood Mage and cast it noting happens.

On a side note, I would like to know how to programmatically add the spell to Blood Mage (this is some API command I'm sure) so I don't have to build map and open it in WE to test the spell.

 

[Jampion]

If you build the map via VSCode, the map gets copied and the code and the objects are injected into the copied map.
You should not alter the copied map after that in WE. Since the ability id is undefined ( ABIL_ID_GEN.next() ) you cannot even add this ability in the editor, as the id might change if you rebuild after you added some other abilities.

The copied map has the code in the map script. If you open the map in WE and resave it the code is replaced by the code generated from WE, so you remove all your wurst code.

You can add

gg_unit_Hblm_0000.addAbility(SPELL_ID)

to Conflagration init

and add

• Untitled Trigger 001
  • Events
  • Conditions
  • Actions
    • Unit - Kill Blood Mage 0000 <gen>

in the WE. This makes sure that the variable gg_unit_Hblm_0000 is correctly used in the map script even though the trigger never runs.
Alternatively you could use unit group loops to find the Blood Mage. Then you don't have to use the WE.
Or just remove the Blood Mage in the WE and create it in wurst, so you can easily refer to it in wurst.

Also no effect is created (I have noticed Art - Effect is null, as are other Art related fields)

This is intended:
new ChannelAbilityPreset(SPELL_ID, 4, true)
The last boolean argument removeChannelProperties makes sure the ability performs like a normal ability and does not have all these effects. It also makes the ability visible.

 

[xylon]

Thanks for your reply! It is now working, altough the ability is not added as a hero ability (therefore can't level up, is there some "addHeroAbility" method the autocomplete doesn't show?).
I feel that the documentation for Wurst is kinda short (for that reason I am writing a guide as I learn and will submit it in the future), although the language itself is delicious (pun intended).

However I got a new (workflow-related) question from your post. You say:

You should not alter the copied map after that in WE.

If you open the map in WE and resave it the code is replaced by the code generated from WE, so you remove all your wurst code.

Now if I read that correctly, my friend (doing terrain and other not coding related stuff) would not be able to get my map and then modify it with his own stuff then send it to me to add code? (because that would "destroy" the previous iteration of the cycle, deleting my previous code when he saves in the WE)
Or to rephrase it in a more general question:
How should we organize the workflow? / How do people typically organize their workflow? Given your two quotes.

 

[Jampion]

I feel that the documentation for Wurst is kinda short

You can look up what each function does in VSCode by holding ctrl and clicking on the function. Most of the time it just takes you to a JASS native. For example unit.addAbility -> UnitAddAbility
The problem is that JASS is not well documented. You usually only find the signature. Over time you get used to the naming convention and will understand pretty fast what most functions do.

There is a new native to remove a hero ability, but I can't find one to add a hero ability:
native BlzDeleteHeroAbility takes unit whichUnit, integer abilCode returns nothing

How should we organize the workflow? / How do people typically organize their workflow? Given your two quotes.

A wurst project contains all the files needed to build the map. Once the map is built (base map is copied and wurst code and object data is injected into the copied map), you must not save the already built map in the editor anymore or you will lose your code.
The base map can of course be changed as often as you want. You just build the map again, if you want to test or release it.
The base map is just a normal map that can be opened by the editor without problems. The built map is not normal because its map script was modified by wurst. When you open a map in the editor the map script is ignored and the trigger data is loaded from a different file. Wurst does not change this file, so when you open the map in the editor it looks like the code was not modified at all. When saving the editor creates the map script again based on the current triggers in the editor effectively overwriting all your wurst code.

You never work on the wurst generated map. You work on your files in the wurst project (source code, base map, imports). Building the map is the last thing you do.
So your friend has to work on the base map.

Now if I read that correctly, my friend (doing terrain and other not coding related stuff) would not be able to get my map and then modify it with his own stuff then send it to me to add code? (because that would "destroy" the previous iteration of the cycle, deleting my previous code when he saves in the WE)

You send him the base map, he modifies it with his stuff, sends it back to you and then you build the map. There is nothing you can destroy here, because the base map does not contain any wurst code.

He must not modify the built map. If he does, saving will overwrite the map script, so you would have to build again to have the code in the map.
One big issue with modifying the built map is, that it contains the injected object data and they will be loaded by the editor just fine. Now if you would want to build again you will get problems, because the map already contains the injected object data and you cannot inject it again. So a map that was built with wurst once, cannot really be be built again. This is why you always need a clean base map.

Just remember to seperate base map from built map. Always have a clean base map that is never modified by wurst. Never modify the built map.

The described process ( sending base map to friend, modifying terrain, sending map back to you, building map, sending built map to friend ) is very lengthy. You should use git, so both of you have access to all the files. This allows you friend to build the map on his own and test it with code. Wurst works very well with git.


If you are familiar with map archives, you can compare the base map and the built map in an mpq editor. That could help understanding all of this. (make a backup of the base map before that)

 

[xylon]

Thank you