• 🏆 Texturing Contest #33 is OPEN! Contestants must re-texture a SD unit model found in-game (Warcraft 3 Classic), recreating the unit into a peaceful NPC version. 🔗Click here to enter!
  • It's time for the first HD Modeling Contest of 2024. Join the theme discussion for Hive's HD Modeling Contest #6! Click here to post your idea!

Challenges with UMSWE/WEU

Status
Not open for further replies.

MindWorX

Tool Moderator
Level 20
Joined
Aug 3, 2004
Messages
709
I frequently get questions about UMSWE/WEU features, which I have been hesitant in implementing.

The issue with UMSWE/WEU is that it adds some changes which can result in maps being dependent on the editor. This makes maintaining your map a problem if any of these features ever gets removed. People have already been experiencing this after JNGP broke and their maps being completely unopenable without it. It also has a negative effect on other systems trying to parse your map, since the map is complete garbage without the UMSWE/WEU changes.

Because of this, I've been hesitant in adding it back in as a default feature.

What I have considered is adding a limited version of it back, with only the non-breaking features, which means it'll mostly just be the UI changes, like raw id in the object editor.
 
Level 12
Joined
Mar 13, 2012
Messages
1,121
I do not see a big problem with maps becoming dependant on the editor, it's just a requirement for extended features. As Daffa said, if the editor is in active development it's no problem. Open Source is a nice safety net here. I mean if we count VJASS, WEX maps are already dependant on WEX, right?

The problem I see is with the editor unlocking features the game might not support in the future.

Every additional feature should be considered separately how likely it is to break ingame in the future.

Can you name what is on your list?
 
Status
Not open for further replies.
Top