[Release] WurstScript - A Wurst to Jass Compiler & IDE

[bhusta]

The standard library is a pretty neat feature which most people reading this thread realy don't get. One can already use all of the important systems/packages just by opening a new project. It is great benefit that one does not have to import all the systems manually.
There is even a wurst version of file i/o and other famous systems.

Maybe you could post a brief list of packages which are ready to use.

Edit: The only thing missing is a proper highlighting and a section for wurstscript on THW.

 

[edo494]

I dont talk from my experience, because I have none with Wurst, but one unnamed person(or more) were claiming those systems are suboptimal compared to the vJass ones

 

[Frotty]

I dont talk from my experience, because I have none with Wurst, but one unnamed person(or more) were claiming those systems are suboptimal compared to the vJass ones

Then stop being a "jump of cliff when told"-guy and get an ideaoif wurstscript yourself?
You post a lot in this thread without having tested it out?
I think we stated often enough that we aim against premature optimization and rather have good readabiliy, ease of use and comfort than a few nanoseconds faster execution speed.
The systems in the stdlib are pretty spot-on an nowhere near imperformant.
Again, as already noted before, wurst also makes way more optimizations to the generated code than jh and the map optimizer.

Going further, by opening a ticket on github you can easily request any system/package you would like to see in the stdlib.
As bhusta said, having the stdlib removes the need of searching for and custom importing systems that rarely work together in most cases. It provides easy and instantly useable resources that are used in almost every map.
It therefore increases deployment- and learningspeed as well.

 

[peq]

using vJass with wurst

I have now finished a first prototype for integrating vJass with Wurst. This works as follows:

• Jasshelper is now integrated into Wurstpack
• If Jasshelper is enabled it will run before Wurst
• Wurst can use the output created by jasshelper and Wurst-code can call functions from the jasshelper output. Therefore calling plain functions is very easy. Using structs is also possible, because structs are translated to plain functions. The other direction (calling wurst functions from vJass) is not possible.
• The output of jasshelper is stored in your Wurst-folder, so the eclipse plugin can see the file. This makes it possible to find functions via autocomplete and it allows to start the map from eclipse directly without calling jasshelper again. This makes the process of testing a map much faster.

I think that this approach is a good way to migrate a map from vjass to Wurst, since the migration can now be done incrementally. You can migrate a single spell to Wurst and already test the result. Or you can just start writing your new spells in Wurst and keep the old spells as they are.


You could also use the wurst compiler just for its optimization features (froptimizer). That way you can stop setting variables to null in your vJass code, since it will be done automatically by Wurst. And you can finally stop writing 100-line functions just because JassHelper does not have a good inliner.


I still need to work on the documentation of all this and the other features we added recently.

 

[PurgeandFire]

You might want to update the main post with the info on compiletime functions (since they are already implemented, right?). I didn't notice they were implemented until I saw muzzel use them in a script.

 

[Crigges]

Well the first post just contains a small overview about wurst. All wurst features with an explanation and exampels are inside the wurst Manual. So if you want to learn more about compiletimefunctions read this.
Wurst got a lot new features since the release here just a few of them:
-Start maps out of eclipse
-Closures
-Stacktrace debug messages at runtime

 

[edo494]

you should keep this post up to date, because this post is the representation of Wurst on this forum, not some github page

 

[Frotty]

you should keep this post up to date, because this post is the representation of Wurst on this forum, not some github page

Of course it is, but there didn't seem too much interest in the project so I am too lazy to update the presentation every week if no1 even notices.

 

[bhusta]

Of course it is, but there didn't seem too much interest in the project so I am too lazy to update the presentation every week if no1 even notices.

But you can't assume that the interest increases if you keep the cool stuff all by yourself

A weekly update wouldn't be necessary but for example compiletime functions alone are powerful enough as a reason to start with WurstScript.

 

[peq]

We have updated the first post with some of the newer features like closures and compile-time functions.

 

[Troll-Brain]

I'm just curious (and can't test it), the naming convention written in the documentation must be used in order to "compile" the code correctly or it's just a recommendation ? A "must" or a "should" ?

 

[Frotty]

I'm just curious (and can't test it), the naming convention written in the documentation must be used in order to "compile" the code correctly or it's just a recommendation ? A "must" or a "should" ?

It's a must

 

[Troll-Brain]

Hmm, that should be a con from an user point of view. I understand that it makes the "compiling" much easier, i'm just adding my 2 cents.

 

[muzzel]

Hmm, that should be a con from an user point of view. I understand that it makes the "compiling" much easier, i'm just adding my 2 cents.

Its always difficult to settle on naming conventions since its a matter of personal opinion.
However enforcing one coding standard (not important which one) is necessary to prevent users from mixing different conventions.

In Jass there is no enforced standard and everyone just does what he wants. This makes reading foreign code much harder.

 

[Troll-Brain]

Well, usually we have conventions which are recommended and not absolutely be followed in order to use a language.
I don't know a language (actually really used and not just some other one) where you must follow the convention. (expected of course some real basic ones such as not begin a word with a number).
And i consider it much more as a personal language that something else, considering how old is wc3 and how young the language is.

Now, again that's just my 2 cents, i personnaly hate indent based languages anyway, i prefer ruby against python just as an example.

 

[edo494]

well, afaik pretty much every programming and scripting language doesnt force any conventions(as I understand this: Function names must start with Big/Small letter etc) so it is a bit of con for user, but for overall readness it is pro

 

[muzzel]

Tbh i dont like indention based languages either, but i have to say it nicely integrates into eclipse and is very comfortable to use. For me its not reason enough to not use Wurst and it doesnt affect my coding efficiency in Wurst, of course it takes some time getting used to it.

 

[edo494]

well, if people indend their code properly, its the same as writing normal code, like mine in C++, but without the { }

 

[muzzel]

Imo using { } feels a little more "explicit". But i agree, its not much of a difference.

 

[Troll-Brain]

That's not the problem edo, for me it makes harder to see each code bloc (function, if, loop, whatever ...), especially when there are many lines of code, it's less neat, but meh ...
I also don't like {}, because of my azerty keyboard. So ruby is "perfect".

 

[peq]

well, afaik pretty much every programming and scripting language doesnt force any conventions

Well, if it is enforced then it is not a convention by definition But there are at least three other languages, where upper case names are enforced:

Haskell: Constructors must start with upper case letter
ABS: Types must start with upper case letter
Erlang: Variables must start with upper case letter, because lower case letter are reserved for atoms

And there are other examples, where a certain naming is enforced. For example in Dart a function is private when its name starts with an underscore, while in Javascript that is only a convention.

That's not the problem edo, for me it makes harder to see each code bloc (function, if, loop, whatever ...), especially when there are many lines of code, it's less neat, but meh ...

I guess this is only a problem in the beginning and you would get used to it. If your functions get so long or so nested that you have problems seeing the different indentation levels, you might have other problems.

I am not sure if we would choose the same syntax again, if we started the project again. There are some problems when copy&pasting code and the syntax for multi-line anonymous functions is a bit awkward now. But overall the benefits of the current syntax outweighs the drawbacks in my opinion.

It is also interesting how Haskell allows using indentation or braces, but everyone uses the indentation based syntax.

 

[Adiktuz]

Ruby variables:

$variable => global
@variable => class instance variable
@@variable => class variable
variable/Variable => local
VARIABLE = constant

IDK if it counts as a forced convention for naming, but you are forced to follow those AFAIK...

anyway, how is this project going?

 

[Xonok]

For clarification.

Convention:
"a way in which something is usually done."

They, by definition, are not enforced.
Thus, if you enforce it, then it's already a part of syntax and can't be called convention.

 

[peq]

Debugging vJass with Wurst

Here is a little success story I just had with Wurst.

So someone comes to me because he is getting the error "AutoIndex error: xe unit is a filtered unit." whenever he casts a certain spell and he does not know what the cause for that is. So we start looking at the sourcecode of the spell, add debug messages and do tests. Classical Jass debugging (the map is in vJass). After some time we still have not found the problem. The map takes over a minute to save, as it has a lot of doodads, so testing is really slow. He sends me the map, so that I can also add some debug messages and do other tests in parallel.

But instead of using the classical Jass debugging method, I compile the map with vJass and Wurst, then go to eclipse and replace the BJDebugMsg with a call to the builtin "error" function of wurst. Then I start the map from eclipse, which is much faster than starting it from WE, because the doodads don't have to be saved again. When casting the spell, I get nice stack-traces from Wust:

The stack-traces shows the line numbers of the function calls leading to the error. The origins of the calls were actually in two completely different spells, which had a unit-cast-event and reacted to dummy-casts triggered by the knockback system used by the spell which we thought to be the problem.

I think finding the real cause of this problem would have been much harder with the traditional debugging methods.

Btw: If you use Wurst instead of vJass, then the stacktraces will give the correct filename and not all point to "war3map".

The idea for stacktraces actually comes from Müslirocker, who already implemented them for Jass some years ago.

 

[muzzel]

Very nice (or "krasser scheiss"), i guess il have to check out those stacktraces myself some time.

 

[pred1980]

yes, that was story my friend

 

[peq]

I have now put together a changelog file from the last few months.

In the future I will try to keep it up to date and always post the new changes here.

Version 1.3.0.0
==================

### Language Features:

* There now is a warning for unused variables.
* The optimizer (local optimizations) is now more aggressive when inlining local variables.

### Tools:

* New Updater (still beta, not part of the WurstPack release yet)
* Changed MPQ editor to Jmpq (loading StormLib via JNA). With this change it is now possible to compile and run Maps
from Linux systems. Macs should also be supported, but this has not been tested yet.
* WurstPack now adds an option for starting the map with SharpCraft, when there is a SharpCraft folder in WurstPack (not included by default).

### Standard library:

* Many functions which used to return 'this' now return nothing. Use the cascade operator for chaining method calls.
* LinkedList: LLIterator is now public
* Some new functions for vectors.
* New package: ClosureForGroups

### Bugfixes:

* Fixed bug #193: Inliner could remove the global init func and mess with later phases in translation.
* Fixed a bug where closures did not work with tuples correctly.
* Fixed bug in tuple elimination
* Fixed bug #187: optimizer removed compiletime functions before they could run.
* Fixed problem in interpreter, where dynamic dispatch no longer worked after recompile.

Version 1.2.0.0
==================

### Language:

* Added [cascade operator](http://peq.github.io/WurstScript/manual.html#cascade_operator_dotdotoperator) (`..`) for chaining method calls
* Anonymous functions can now be used where a `code` expression is expected.
* A newline at the end of wurst files is no longer necessary
* Anonymous functions can now have an expression with a return value if no return value is expected.
* `destroy x` is now an expression. This means it can be used in anonymous functions more easily.
* Better type inference when calling generic functions

### Tools:

* Eclipse REPL now uses toString function to print results.
* Eclipse REPL now tries to resolve imports
* Improved autocomplete
* WurstPack now supports JassHelper. It is possible to run JassHelper before Wurst and so have limited support for both languages in the same map.

### Standard library:

* ClosureEvents package

### Bugfixes:

* CRITICAL BUG. Changed id-recycler back to simple stack based because of bugs.

Version 1.1.0.7
=========================

### Language:

* It is now possible to call ExecuteFunc with a constant string argument
* It is now possible to have natives in the mapscript. Natives can be annotated with `@extern` if they should not be included in the map script.

### Tools:

* Progress bar in WurstPack is now more precise
* Running a map from Eclipse should be much faster now.


### Bugfixes:

* Fixed a small bug in the backup controller.
* Fixed handling of int-reals subtyping in jass
* Fixed bug in unit object editing (many fields where declared with type `real` but actually had `unreal`)


Version 1.1.0.6
=========================

### Language:

* Added [stacktraces](http://peq.github.io/WurstScript/manual.html#stacktraces)

### Tools:

* Maps can now be launched from Eclipse
* war3map.j is now saved in wurst folder when compiling a map from WurstPack. This makes it possible to use constants from the map in Eclipse.
* Eclipse: Fixed bug in text-hover
* Some improvements of the REPL
* Eclipse: Improved configuration of syntax highlighting
* Eclipse: Hovering over variables, function-calls etc. now shows some nice information.

### Bugfixes:

* fixed error message, when type args could not be inferred
* several fixed related to object editing
* fixed bug in closure translation, when closure implementation had type void


### Standard Library:

* ClosureEvents and ClosureTimers packages

Version 1.1.0.5
=========================

### Bugfixes:

* Fixed bug with overriding+generics
* Fixed bug with `thistype`


Version 1.1.0.4
=========================

* Fixed problems with Eclipse console
* Fixed a bug with inherited generic type params

Version 1.1.0.3
=========================

* only internal changes

Version 1.1.0.2
=========================

### Bugfixes:

* improved error handling in case of a compiler bug
* fixed bug in closure type calculation
* eclipse plugin: fixed problem in repl with generics and improved reconciler behavior in case of parse errors

### Standard Library:

* LinkedList: addded closure functions


version 1.1.0.1
=========================

### Language:

* Added [anonymous functions and closures](http://peq.github.io/WurstScript/manual.html#lambda_expressions_and_closures)
* It is now possible to destroy an object via an interface type

### Bugfixes:

* fixed: check that abstract functions are not private

 

[muzzel]

Nice. This looks more comfortable than having to check the wurstmanual or the github changelogs manually. Although i have to say that these commit messages were always funny to read....

changelogs

Changes
- removed frottys drug influenced code (commit: ac7b089b778586737271472ea3d221a21432b1b2)
- oops (commit: 9d91f09d9303d18a71b7b31760213007c424bbed)
- peq der bozz (commit: 368116153ed4e16185c13febd2423c18dc2b76fd)
- I hope this fixes the bug in the error reporter (commit: 4badf2ddafcac28ab1f9bf3818f0542c1f449077)

 

[Arhowk]

calling vJass from Wurst is not very convenient.

but is it possible?

I'd like to use wurst but I'm not rescripting my project that I've worked on for the past two years.

 

[PurgeandFire]

Cool updates.

* Changed MPQ editor to Jmpq (loading StormLib via JNA). With this change it is now possible to compile and run Maps
from Linux systems. Macs should also be supported, but this has not been tested yet.

Does it work with the map opened in WE on Windows? I just know that StormLib likes to complain when two things are messing with the same file (unless my memory is off, maybe it was just the mpq editor and not StormLib itself). Or is JMpq going to be just for Linux/Mac users?

 

[Chomtana]

I have this error after compile map with new version

 

[peq]

but is it possible?

I'd like to use wurst but I'm not rescripting my project that I've worked on for the past two years.

This graph shows the translation process:

Because the vJass output is merged with the Wurst code, it is possible to call functions in the vJass output from Wurst. However those functions usually have strange names, like s__spellfireball__data_struct__allocate. Calling Wurst functions from vJass is not possible, because the Wurst code is added in a later step.

Does it work with the map opened in WE on Windows? I just know that StormLib likes to complain when two things are messing with the same file (unless my memory is off, maybe it was just the mpq editor and not StormLib itself). Or is JMpq going to be just for Linux/Mac users?

Eclipse will copy the map and work on the copy, so it is possible to have the map opened in WE. Jmpq currently includes the stormlib library for windows 32 bit, windows 64 bit, linux 64 bit, and mac 64 bit, but I could only test windows 64 bit, linux 64 bit so far.

 

[peq]

I have this error after compile map with new version

Ok, looks like you have 32bit windows. Probably I have put the dll in a wrong folder.

Edit: Should be fixed now. Unfortunately I cannot test it, because I don't have win32.

 

[Chomtana]

Ok, looks like you have 32bit windows. Probably I have put the dll in a wrong folder.

My OS is Windows 7 64-bit

 

[peq]

My OS is Windows 7 64-bit

Hm, maybe you have 32 bit Java installed. If that is the case I could probably test it on my machine, too. Have you tried if it works now?

 

[Chomtana]

I download new compiler and it works now

 

[PurgeandFire]

I get this error when I try to do File -> New -> Project -> Wurst Project -> "Next >".

java -version

java version "1.7.0_45"
Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)

edit: It is most likely an error on my end regarding the java version. I'll try to see what I can do, but I'm open to suggestions.

 

[peq]

java -version

java version "1.7.0_45"
Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)

edit: It is most likely an error on my end regarding the java version. I'll try to see what I can do, but I'm open to suggestions.

Maybe you have two versions of Java installed and eclipse is running with the older version. To see the one Eclipse is runing under, go to Help->About Eclipse Platform->Configuration Details, and look for the property eclipse.vm.

You can also configure it: http://wiki.eclipse.org/Eclipse.ini#Specifying_the_JVM

Wurst requires Java 1.7.

 

[Zwiebelchen]

I'm following this thread for quite a long time and haven't had the balls to convert over to Wurst simply because I got years of experience with the vJass syntax and Newgen WE, that I simply can not afford the time to learn something new. :/

However, I really LOVE the compiletime functionality to create object data.


I would love to see an extra standalone editor just for that!
Basicly all it should be able to do is injecting object data into the mpq based on the editor input. Can you guys do that?

It be even better if it also comes with a list of all available art resources (all sounds, .blps and .mdl/.mdx files in the mpqs plus imports in the map mpq) to copy and paste the paths on the fly.


To be honest, I never had a real issue with vJass over the years. I got so used to it that I don't care about its flaws anymore. What I do care about, however, is the flaws the actual WC3 map editor has (terribly slow compiling, ridicolously slow and inconvenient GUI object data creation).

If you could kill those flaws by creating a robust, text-based object editor, you guys will be my personal heroes.
Fuck, I would even PAY for this!

 

[Frotty]

I'm following this thread for quite a long time and haven't had the balls to convert over to Wurst simply because I got years of experience with the vJass syntax and Newgen WE, that I simply can not afford the time to learn something new. :/

However, I really LOVE the compiletime functionality to create object data.


I would love to see an extra standalone editor just for that!
Basicly all it should be able to do is injecting object data into the mpq based on the editor input. Can you guys do that?

It be even better if it also comes with a list of all available art resources (all sounds, .blps and .mdl/.mdx files in the mpqs plus imports in the map mpq) to copy and paste the paths on the fly.


To be honest, I never had a real issue with vJass over the years. I got so used to it that I don't care about its flaws anymore. What I do care about, however, is the flaws the actual WC3 map editor has (terribly slow compiling, ridicolously slow and inconvenient GUI object data creation).

If you could kill those flaws by creating a robust, text-based object editor, you guys will be my personal heroes.
Fuck, I would even PAY for this!

Well The Eclipse-Plugin basically is your editor for that, and it's FREE (yay).
If you followed the last posts you should have seen that vJass can be used alongside with Wurst so you don't have to "convert" your whole script.
Also you can launch your map from eclipse and it has autocomplete etc. for the object-editing.

 

[Zwiebelchen]

Well The Eclipse-Plugin basically is your editor for that, and it's FREE (yay).
If you followed the last posts you should have seen that vJass can be used alongside with Wurst so you don't have to "convert" your whole script.
Also you can launch your map from eclipse and it has autocomplete etc. for the object-editing.

The thing is: I'd need to switch back and forth between the WE and the eclipse plugin to get all the art asset paths. It would be really convenient if it would come with a complete list of data paths for the specific fields so that I wouldn't need to run the editor in parallel.


EDIT:
Let's say I have a function for an internal item registry in my map where I store custom stats, attachment model path, etc.. I want to add data fields to it that automaticly generate object data based on the input fields. Can I do that?

Let's say my function used to register objects to my map systems looks like this:

call registerItem(Rawcode, iconpath, name, itemtype, tooltip, ability 1 raw, ability 2 raw, ... , ability 5 raw, goldcost, woodcost, ...)

Can I add the needed compiletime functions to my registerItem function to do that without even opening the object editor (assuming all of them are pre-defined constants, of course)?

Can I make Wurst to remove all unneeded data fields from the function after adding the required object data on JASS level and only leave those that are not manipulating object data?


Having both an item-system internal text based item registry AND object data to manage from two seperate locations is a real pain in the ass. It also leads to a lot of bugs if you forget to add for example a certain item ability.

Even more advanced: Could I make wurst to automaticly create the tooltip based on the data fields I enter?

Lets say I want to create an item that has 5 agi, 7 int and 3 of a custom stat that only exists inside an external item system and does not need item abilities.

The optimal thing would be if I could use one single line of code where I input all the custom and wc3-default stats and it automaticly creates the required object data and item tooltip based on that.


or generally spoken: Can I create a nested compiletime function that creates both code and object data?

Basicly the same thing textmacros did.

 

[peq]

So if I understood you correctly, you have the data for the objects in your vJass code and want to create objects from that. Theoretically this is possible, but you will probably have to restructure your code.

You need to have a description of your data (can be in vJass) which is completely decoupled from the in-game logic. Then both the object generation and the in-game scripts can use that data.

I'll try to write a small guide with examples on the weekend.

 

[muzzel]

When i was playing around with wurst i came across this problem, creating compiletime- and runtimeobjects based on the same datasource. This is what i found to be the prettiest solution:

package Test
import UnitObjEditing

function itemRegistry()
	registerItem('I000', "ReplaceableTextures\\CommandButtons\\BTNThunderLizardEgg.blp", "Battle Helmet", 0, 12, 360)
	registerItem('I001', "ReplaceableTextures\\CommandButtons\\BTNPenguin.blp", "Penguins Mask", 7, 6, 440)
	registerItem('I002', "ReplaceableTextures\CommandButtons\BTNSpiritWalkerAdeptTraining.blp", "Killershredder", 32, 0, 240)
	
	
function registerItem(int rawcode, string iconpath, string name, int damage, int armor, int goldcost)
	if compiletimeMode
		// Create tooltip:
		var tooltip = ""
		if damage != 0
			tooltip += "\nDamage: +" + damage.toString()
		if armor != 0
			tooltip += "\nArmor: +" + armor.toString()
		// Create object:
		new ItemDefinition(rawcode, 'ches')
			..setInterfaceIcon(iconpath)
			..setName(name)
			..setGoldCost(goldcost)
			..setTooltipExtended(tooltip)
	else
		// store values in hashtable or whatever...

boolean compiletimeMode

@compiletime function genObjects()
	compiletimeMode = true
	itemRegistry()
			
init
	compiletimeMode = false
	itemRegistry()

Short explanations for those who dont use wurst:
- The "init" block is executed when the map is loaded, similar to library initializers
- The "@compiletime" function is executed when the map is saved
- The Wurst Optimizer will remove the "if compiletimeMode" branch from the map script as it is always true at runtime (At least in future versions it will remove them).

You can also let the script generate the rawcodes and return them to your runtime objects.

I havent yet tried to split this up in a Wurst and a vJass part.

 

[Zwiebelchen]

When i was playing around with wurst i came across this problem, creating compiletime- and runtimeobjects based on the same datasource. This is what i found to be the prettiest solution:

package Test
import UnitObjEditing

function itemRegistry()
	registerItem('I000', "ReplaceableTextures\\CommandButtons\\BTNThunderLizardEgg.blp", "Battle Helmet", 0, 12, 360)
	registerItem('I001', "ReplaceableTextures\\CommandButtons\\BTNPenguin.blp", "Penguins Mask", 7, 6, 440)
	registerItem('I002', "ReplaceableTextures\CommandButtons\BTNSpiritWalkerAdeptTraining.blp", "Killershredder", 32, 0, 240)
	
	
function registerItem(int rawcode, string iconpath, string name, int damage, int armor, int goldcost)
	if compiletimeMode
		// Create tooltip:
		var tooltip = ""
		if damage != 0
			tooltip += "\nDamage: +" + damage.toString()
		if armor != 0
			tooltip += "\nArmor: +" + armor.toString()
		// Create object:
		new ItemDefinition(rawcode, 'ches')
			..setInterfaceIcon(iconpath)
			..setName(name)
			..setGoldCost(goldcost)
			..setTooltipExtended(tooltip)
	else
		// store values in hashtable or whatever...

boolean compiletimeMode

@compiletime function genObjects()
	compiletimeMode = true
	itemRegistry()
			
init
	compiletimeMode = false
	itemRegistry()

Short explanations for those who dont use wurst:
- The "init" block is executed when the map is loaded, similar to library initializers
- The "@compiletime" function is executed when the map is saved
- The Wurst Optimizer will remove the "if compiletimeMode" branch from the map script as it is always true at runtime (At least in future versions it will remove them).

You can also let the script generate the rawcodes and return them to your runtime objects.

I havent yet tried to split this up in a Wurst and a vJass part.

I just came. This is awesome! I seriously consider getting eclipse and wurst just for this single feature. Automated creation of both compile- and runtime data including tooltips is my wet dream when creating items.


Can the script be expanded to check if an item ability awarding item stats like armor/damage/int/agi/str exists and if not, creates the required object data aswell?

A current problem I got when creating items is that I constantly need to create new item abilities for those vanilla item stats based on how much those items need. I can not use a binary system for that as item abilities are limited to 5, so if I want an item to have 17 int, I need to create an extra ability for that first, etc.

well...
... The more I think about this, the more I think about getting rid of item abilities at all and manually applying the Armor/Attack/Int/Agi/Str scores by trigger. Probably the better solution.


Btw, I don't really need Wurst to disable the compiletime stuff automaticly. As I can just comment out everything after saving.


What would the above script look like if I want Wurst to automaticly scan my current rawcodes and create objects based on unused rawcodes and then automaticly pass them over to the runtime registry (in a hashtable)?

I already got an ordinary Jass registry function ready to go. So no need to actually apply vJass here. I just run that function inside the runtime stub and it should work fine.

 

[muzzel]

Can the script be expanded to check if an item ability awarding item stats like armor/damage/int/agi/str exists and if not, creates the required object data aswell?

Unfortunately im quite sure its not possible to read objectdata using Wurst, you can only create new objectdata or modify existing one.

This isnt a problem when you create ALL your objectdata using wurst. When you require an ability you could use a hashmap to check if that ability already exists (if not you create it and store it in the hashmap). But again that only works if you create all your items and abilities via Wurst ObjectGen.

A current problem I got when creating items is that I constantly need to create new item abilities for those vanilla item stats based on how much those items need. I can not use a binary system for that as item abilities are limited to 5, so if I want an item to have 17 int, I need to create an extra ability for that first, etc.

well...
... The more I think about this, the more I think about getting rid of item abilities at all and manually applying the Armor/Attack/Int/Agi/Str scores by trigger. Probably the better solution.

I agree, you anyway use Bonusmod to apply statchanges caused by buffs, why not use them for items aswell. This even would reduce loading time as you can get rid of many abilities.

 

[Xonok]

Note that spellbooks can also be put on items. This should somewhat fix your problem, Zwieb.

 

[peq]

The question about reading objects comes up quite often. Technically it would not be a big problem since we have to read the object data anyhow. The reason for not adding this feature is, that with the current design it is not necessary to run the compile time functions every time the script is compiled. If it would be possible to read object data and "pass" it to the runtime phase, then it would become necessary to do this on every compile.

 

[muzzel]

If it would be possible to read object data and "pass" it to the runtime phase, then it would become necessary to do this on every compile.

Couldnt the objectdata be buffered in a file that is read by the wurst compiler? When saving with compiletime functions enabled that file is renewed.

Anyway im not sure if this feature is really required. I personally find it more convenient to generate all objectdata using wurst.
But hey, it wont harm. If its not too much work to add it then its probably a good idea.

@Xonok: i dont quite understand how spellbooks solve this problem?

 

[peq]

Couldnt the objectdata be buffered in a file that is read by the wurst compiler? When saving with compiletime functions enabled that file is renewed.

Hm, but what if you save without compiletime functions and the buffer file is not there. Should it run compiletime functions automatically? What if you add a unit via the object editor and forget to rerun compiletime functions? Then you can get different maps for different compiles, which could be a problem when working in a team when sharing the map and the scripts but not the buffer file.

 

[Nestharus]

Hm, but what if you save without compiletime functions and the buffer file is not there. Should it run compiletime functions automatically? What if you add a unit via the object editor and forget to rerun compiletime functions? Then you can get different maps for different compiles, which could be a problem when working in a team when sharing the map and the scripts but not the buffer file.

That's how my Lua stuff worked.

You can put the file right into the mpq archive so that it gets passed around with the map. On final compilation (release version), you can optimize it away (remove it from the mpq archive).

Alternatively, you can create a new project format and include the mpq format + w/e extra files you need in the project.