HomeUser Control Panel (unavailable in archive)ForumsTutorialsArt GalleryResourcesMaps

UMSWE 4.0

09-27-2003, 07:57 PM#31
dataangel
Quote:
@dataangel:
About the speed:
There is a hardcoded limit in Warcraft III for the speed. 400 is the limit for normal movement. A bit higher is the limit for wind walk. Regardless of the value you set it, it will not be higher than the limit.


I know. That's the thing. You've changed the max in gameplay constants to be 65,000 -- but this is a pointless change because the max speed is hardcoded :P I guess it doesn't do any obvious harm, but I can see someone who doesn't know about the hardcoding reporting this as a bug or thinking that something is wrong with their triggers instead of with umswe4/war3.

And another suggestion: The light sources tutorial can be improved. If a unit is given the Unknown (Aloc) ability, then it can't be selected. Then there's no need for the triggers described.
09-27-2003, 07:58 PM#32
dataangel
Quote:
Originally posted by PitzerMike

About local variables: No, there's no way to make them available for GUI triggers


That seems wierd to me since it's possible in the GUI with custom script code. But then again I haven't actually tried to edit the editor...
09-28-2003, 05:14 AM#33
Telperion01
Ok, I've encountered an odd bug where the abilitydata file of a Map A mixes with that of a Map B when I open it in UMSWE (didn't happen in the regular editor or older versions of UMSWE). I've checked my wc3 root directory, map directory, everywhere else for an abilitydata.slk or the like floating around, but there is none. What should I look at to fix this?

Here's an example of what part of the abilities in map B looks like when opened with UMSWE:
09-28-2003, 06:11 AM#34
Starcraftfreak
Quote:
Originally posted by dataangel
That seems wierd to me since it's possible in the GUI with custom script code. But then again I haven't actually tried to edit the editor...

It works only if you put it at the beginning of the trigger actions. As soon as you add something else before a custom script local, it won't work.
It's hard to explain, but we can't add support for locals.
BTW guys, suggestion go here: http://www.wc3campaigns.com/forums/s...threadid=21493
09-28-2003, 09:25 AM#35
PitzerMike
I think I can solve that AbilityData problem.
It's quite simple. The AbilityData.slk in UMSWE.exe overrides the one in your map. Not only in the editor, it actually gets imported into your map instead of the old one.
This always occurs if a self-executable mpq contains a file with the same name you already imported. I don't know why, maybe this hasn't been the case in older versions of MPQ draft...

//Edit: Put the AbilityData.slk of the map you are currently working with in your local Units\ and Custom_V1\Units\ folders to override the UMSWE ones
09-28-2003, 07:41 PM#36
Starcraftfreak
Quote:
Originally posted by PitzerMike
I think I can solve that AbilityData problem.
It's quite simple. The AbilityData.slk in UMSWE.exe overrides the one in your map. Not only in the editor, it actually gets imported into your map instead of the old one.
This always occurs if a self-executable mpq contains a file with the same name you already imported. I don't know why, maybe this hasn't been the case in older versions of MPQ draft...

//Edit: Put the AbilityData.slk of the map you are currently working with in your local Units\ and Custom_V1\Units\ folders to override the UMSWE ones

That's a good discovery (good to know), but it makes things bad.

About the color code presets: I fixed the quotes and they don't work yet. I know why. It's something we can't fix. I already posted at B.net to get something out of Brett_Wood.
Post at B.net

To fix some of the bugs I created a hotfix: http://umswe.wc3campaigns.com/UMSWE4.0Hotfix.zip
09-29-2003, 06:44 AM#37
JollyOven
Its a side effect of how MPQDraft works. Whenever the proggy tries to load a file, if the file is in the patching mpq, that one is loaded instead of whatever the program tried to load. The only way to fix this issue would be to watch where the file is coming from, and if it isn't one of the things that needs to be patched, don't fiddle with the process. However, this is not the type of thing that can be built into MPQDraft, as it is not intended to be program specific. It may be possible to do this with a plugin, but I'm not entirly sure.

If this didn't happen with older vers (although I'm pretty sure it does) then it is most likly the result of MPQDraft being updated to actually patch war3 correctly.
09-29-2003, 01:40 PM#38
Draco
So UMSWE actually imports files into your maps? :bgrun:
09-29-2003, 01:57 PM#39
Vexorian
Not UMSWE, mpqdraft, A way to fix it may be extracting the UMSWE files to the warcraft III dir, well I already do that since I use a direct link to my map at the desktop
09-29-2003, 06:58 PM#40
Starcraftfreak
Neither UMSWE nor MPQDraft "imports" files into your map. It's just IF you import a file and save your map, the file may be replaced with the UMSWE version. This is caused by MPQDraft.
09-29-2003, 07:32 PM#41
Draco
Lol, maybe you should stop that then. :D
09-29-2003, 08:22 PM#42
Scio
that cant be stopped you have to import your own files AFTER you edit, its always been that way.
09-29-2003, 08:55 PM#43
Draco
Why go through the hassle of doing that? What exactly are you using MPQDraft for? Just to execute your version of world edit?
09-30-2003, 12:10 AM#44
Scio
MPQDraft allows you to override our files without overwriting them and to run multiple versions of the editor. Even if we didn't do that, having the individual files STILL overwirtes your files if you dont import them after editing. You do understand we are talking about slks and such modified before 1.10 or edited externally. Normal editing done in the editor still works fine.
09-30-2003, 12:46 AM#45
JollyOven
MPQDraft alows the creation of a selfexecuting MPQ, which when run, will run the target program. Whenever a mpq handling call to storm is made, such as file read, mpqdraft checks the embedded mpq for the file. If it exists, MPQDraft intercepts the call to storm and gives its own reply of the file in the embedded mpq.

This allows mods, such as UMSWE, to be packaged in one clean program.

The problem arises when you try to import a file into your map while patching WorldEdit with MPQDraft. MPQDraft sees an attempt to access a file with the name of a file in the embedded mpq, and supplies that one instead of the intended one. As a result, if you want to imbed any of the files edited by UMSWE, they must be imbedded with normal WE or WinMPQ/etc.

This does not harm normal editing in any way.