- Joined
- Jul 29, 2007
- Messages
- 5,174
I have written code that, given a map/campaign, will try to look for any non-standard GUI and convert it to something that the World Editor understands.
This is mostly relevant to maps made with World Editor Unlimited and its extended GUI.
Here's where you can try it: https://viewer.hiveworkshop.com/weu/
To check a map/campaign, simply drag it into the page.
If there were any changes, the page will download for you the same map, with "no_weu" added to the file name.
Note: Only TFT maps/campaigns are checked, because RoC does not have custom scripts! However, if you have a RoC map with custom GUI, I would like getting it.
Things to expect:
This is mostly relevant to maps made with World Editor Unlimited and its extended GUI.
Here's where you can try it: https://viewer.hiveworkshop.com/weu/
To check a map/campaign, simply drag it into the page.
If there were any changes, the page will download for you the same map, with "no_weu" added to the file name.
Note: Only TFT maps/campaigns are checked, because RoC does not have custom scripts! However, if you have a RoC map with custom GUI, I would like getting it.
Things to expect:
- Many custom GUI events/conditions/actions simply expose Jass natives directly. In many cases these can be converted back to something GUI can understand. For example, if
SetHeroStr
is used, and the change is permanent, it can be replaced withModifyHeroStat
.
- If GUI conversion is not possible, custom scripts are used instead. This generally handles most of the changes, usually for simple things like
RemoveLocation
,DestroyGroup
,DestroyTrigger
, and so on. - When a function that accepts
code
/boolexpr
- such asForGroup
andForForce
- has to be converted to custom script, thecode
/boolexpr
part will be converted to a Jass function in the map's header. - RoC control flow blocks, like IfThenElse, ForGroup, and ForForce, may be converted to their TFT versions, such as IfTheElseMultiple, in cases where it will allow to only convert a part of them, rather than the whole blocks.
- Preplaced objects that will lose all GUI references to them due to the conversion are referenced in an added trigger called PreplacedObjectReferences. This trigger is off by default and has no events, so it won't actually run. It contains actions that reference the needed preplaced objects. Currently this is done for units and destructables (anything else needed?)
- Custom scripts may be added to conditions. WE has no issue with "actions" being in condition blocks, it just doesn't allow you to add them. Unfortunately this cannot be applied to trigger conditions.
- 1.29 PTR functions who's names were prepended with Blz for non-PTR will be converted in the same manner.
For exampleSetHeroProperName
turns toBlzSetHeroProperName
. - You may see seemingly broken custom scripts ending with /* and beginning with */. This is intentional, as they are one long custom script split into multiple lines.
- Whole triggers may be converted to Jass when needed, but this is a last resort. After all, the goal of this project is to attempt to change the GUI as little as possible.
- After all of the conversions are done, the triggers file gets read again using only the vanilla data to validate the conversions.
- If the map was protected/optimized and has no triggers, they aren't going to magically come back.
- If the map is using real custom functions, such as maps made in YDWE, it's very unlikely that it will run in the game, even if you can open it in WE. You will know when you save it in WE and get syntax errors.
- Vanilla 1.29.2's TriggerData.txt
- WEU's TriggerData.txt
- An updated version of YDWE's TriggerData.txt (taken from here)
Last edited: