wurstscript / WurstScript

Programming language and toolkit to create Warcraft III Maps
https://wurstlang.org
Apache License 2.0
225 stars 30 forks source link

editing standard units at compiletime #902

Open rhazarian opened 5 years ago

rhazarian commented 5 years ago

Wurst has a very good support of creating custom units/destructables/etc. at compiletime, but the sad thing is that we cannot use these tools to modify existing custom units, e.g. I cannot change footman abilities.

That's sad, cause it is the only case when you have to work with World Editor except terraining. It would be cool if everything except terrain was possible to do in Wurst, so that the only thing you would have to do in the Editor is to prepare terrain templates.

Probably it could be easily supported using the existing stuff, i.e. by adding a @compiletimenative function getObjectDefinition(int id) returns ObjectDefinition in ObjEditingNatives, which would throw an error if there is no object with such id. The rest needed to support the feature could be done in stdlib.

Frotty commented 5 years ago

Modifying default units just shouldn't be done in the first place. It's terrible practice. What's your reasoning?

rhazarian commented 5 years ago

I'm creating an RP map, where players can hire any units limitlessly, place them on map everywhere, create their stories, etc. It's like SotDRP/RotRP. These maps are not very popular among all Wc3 players, but are very popular in groups of roleplayers. So, I would like to modify standard units by removing gold/lumber cost and some other minor things, and then inject the system in different terrains. Copying all standard units would require a lot of hand work and will create tons of custom objects, which, I think, may be not good.

I believe that there are also other cases, for example, if you do a simple standard-like map with custom races and want to fix balance, or something like this.

peq commented 5 years ago

The reason we don't support this is the following: We want object creation code to be independent from old runs. For new objects we achieve this by marking all objects that wurst creates. Then on compile, we first remove all marked objects and then create everything again from the current compiletime code. This ensures that you can remove object editing code and also have the corresponding changes removed from map.

If we allowed editing of existing objects, this simple solution would no longer work.

If you have suggestions for different solutions or workarounds we can discuss it here. But maybe the easiest solution is really to just create copies for all the units. It should not be too difficult to get all unit ids and generate the basic code to create copies from this. I wouldn't worry about having too many custom objects as wc3 only stores the difference to the original anyways.