Page 1 of 12

SC2 BETA Editor findings

Posted: Thu Apr 22, 2010 10:02 pm
by Ricky_Honejasi
So it's intended to be the main thread to discuss about the editor and especially what you find of considerable interest so far.

Since the object editor has a few too many issues to my taste, I am mostly concentrated on the trigger editor.

1)  With "banks", there is finally a way that you export/import data variable from/on any player's computer. In other words, RPG maps will greatly benefit from it as they no longer to have passwords to write. The big drawback is that the data is written in XML format thus it's really not safe against modifications. Serious mapmakers will probably have to make some trigger systems to prevent easy modifications if they don't desire them.

Code: Select all

<?xml version="1.0" encoding="utf-8"?>
<Bank version="1">
    <Section name="SECTION">
        <Key name="KEY">
            <Value text="LOLADIN"/>

Note that there are also "game tables" that can carry data but I am not sure if it's actually written on the hard drive. Supposedly you can set the game table to "global" or "local".

2) Arrays can finally have up to 4 dimensions instead of being limited to 1 dimension. However, the maximum per dimension is still 8192. However even with 2 dimensions, you have 8192x8192 = 67108864 spaces.

3) Finally a trigger can have GUI local variables. You are no longer forced to code similar to a JASS-equivalent just to benefit from local variables.

4) There is a "Unit takes damage" event  that is actually global (unlike the unit-specific in WC3 that requires backdooring triggering to make it global). Sub-options include firing on fatal and/or not fatal damage, damage type (melee, ranged, spell, splash) and damage effect (probably projectile).

So more as I poke around the editor.

Re: SC2 Editor findings

Posted: Thu Apr 22, 2010 10:27 pm
by UntamedLoli
16 players is doable if you don't need stuff like resources harvestable by all players or passive hostile creeps (changing Neutral and Hostile to actual players) or 14 players and still have everything else.

EDIT: Allies can harvest your owned resources, enemies cannot.

Re: SC2 Editor findings

Posted: Thu Apr 22, 2010 10:30 pm
by Ricky_Honejasi
5 ) It's now easier to select data to preload via triggers. This time, you do have a list of unit, sound, model and so on instead of having to poke into MPQs just to find the paths of files you want to preload. You can even assign files to preload for the next map rather than just for the current map.

6 ) You are no longer forced to use a "locust"-equivalent WC3 ability to make dummy units. You can now do it via the "Unit State" trigger and turning off the following : Selectable, Status Bar, Cursor, Targetable.

7 ) You can modify directly via triggers a specific unit's MAXIMUM health, shields and energy instead of poking odd schemes to achieve any value in WC3. On top of it, you can modify a specific unit's regeneration of any of those 3 in addtion of unit's kills and movement speed.

8 ) There is a "Set Unit Progress" that basically allow to modify any slot's progress on said unit. This include training (Ex : Unit in Slot #4), Construction, research and so on.

9) Seems units can have multiple custom values instead of just one. Custom values are now in real instead of integer.

Re: SC2 Editor findings

Posted: Thu Apr 22, 2010 11:13 pm
by Ricky_Honejasi
10)  "Dialog" is now basically some kind of evolved Multiboard from WC3. It's now an interface where you can put labels, buttons, images, checkboxes and a few other types. Can also modify a dialog's transparency.

Yes, it implies that you can have buttons that does fire a trigger. However, images doesn't seem to fire triggers when clicked on. Fortunately that can be mostly backdoored by having a button under an image with the same sizes/coordinates.

You also show up the dialog anywhere you want on the screen (compared to WC3 Leaderboard/Multiboard that forced you to have it on the top-right).

You can have multiple dialogs at once thus you are no longer limited to 1 leaderboard and multiboard.

You no longer have to fiddle some JASS-equivalent triggers just to show a dialog to a specific player instead of everyone.

There are other features that I didn't cover but I believe I pretty much said the most important ones.

I didn't test yet but SC2's "Leaderboard" at first glance seems to be the WC3's "Multiboard". The name "multiboard" no longer technically exists in SC2.

Re: SC2 Editor findings

Posted: Fri Apr 23, 2010 4:13 am
by Meta
Awesome findings, keep them coming. :D

Re: SC2 Editor findings

Posted: Fri Apr 23, 2010 4:24 am
by IskatuMesk
Regions also have an HDR intensity setting but it always sets back to 1 which I presume is a bug.

Re: SC2 Editor findings

Posted: Fri Apr 23, 2010 5:16 am
by Xenon
Dummy units should be a lot less necessary since you can call effects from triggers (effects being damage, applying buffs etc).

Re: SC2 Editor findings

Posted: Fri Apr 23, 2010 6:53 am
by Ricky_Honejasi
11) Unlike WC3,  if you use the editor's test map functionality, you CAN launch a test again into SC2 via the editor even if your current test map is still running into SC2. In other words, you aren't forced to quit SC2 (like you had in WC3) just to be to be able to start another test.

In WC3, that lack of feature often lead to just not use the test functionality at all on top of having a few side bugs there were compared to just launching the map normally.

This combined with SC2's capacity to remember data (so that you don't reload 100% all the time) from game to game makes that your first launch could take 30 seconds but restarting your test a 2nd time and onwards easily just 1-2 seconds. Thus ultimately, can save you a lot of time just to test some minor changes.

WARNING : I did saw some posts on forums claiming that dualing SC2 and the editor did made them crash. It doesn't seem to be the case for me.

12) There is now a color system that also include a gradient function for text. In other words, you are no longer forced to learn how the color tags works (text thingies) to have colored text (except for modding pretty much, even then you can do it in the editor then copy/paste the version with color tags).

13) You can now detect the mouse's clicks (any button, left button only, right only, middle and 2 extra "buttons" off special mouses) but NOT the mouse movement. Clicks are detectable either in X,Y,Z in the world map or as X,Y on an interface (which I presume to be dialogs).

For example, it means you would be able to click on the map and spawn anything there at a precise map point. For my test, I left-clicked and it spawned a ghost. With combination with a dialog, you could pretty much make a "deployment system" where you select your unit's image (with a button under for detection) off a dialog to click on the map to "position" it.

However, the lack of movement detection or even general mouse's position (that could have been backdoored with timed events) on the screen would prevent in FPS-like maps to have your mouse cursor completely to the right of the screen to turn right and such.

Re: SC2 Editor findings

Posted: Fri Apr 23, 2010 7:12 am
by UntamedLoli
Speaking of testing maps, theres functionality for lighting that it will update ingame as you change it in the editor without reloading.

It might work for other stuff as well but I havn't looked.

Re: SC2 Editor findings

Posted: Fri Apr 23, 2010 7:46 am
by Ricky_Honejasi
14) More as a quick mention, there doesn't seem to have any AI editor but you have multiple AI triggers in the Trigger Editor to better control an AI. There seems to have about 30 basic AI GUI triggers and 30 advanced AI GUI triggers. At a first glance, it seems to give reasonable control over an AI's capacities without learning much about the AI editing files and such.

I have included JPGs as attachments for the various AI triggers. However, I won't be touching AI much since my personal focus never been AIs in all honesty.

15) Many keyboard keys are now detected. You can detect "any" (not sure if it's any keyboard key or any key from the list) or any specific key from the list. In addition, you can allow/disallow any combo of Shift, Alt and Ctrl keys along the detected key. Keys are NOT detected during writing chat text.

It's also much less of a pain to make key triggers since you can have an event like "Press (any key) for (any player)" which you are no longer forced to create EACH key event for EACH player like you had to do in WC3 (for the limited potential keys anyway).

Special note : "Any key" also triggers on Enter (when hitting to pop up the chat text box), it is possible to set a condition to prevent the Enter key to interfere.

Pretty much every keyboard key possible is detectable. This include (but not limited to) : F1 to F12, 0 to 9 (including on keypad), A to Z, arrow keys, escape, space. It includes even odd keys such as Caps Lock, Num Lock, Print Screen, Scroll Lock. An odd key like Scroll Lock could be nice to hide testing options for an author.

Other) Been trying to find a way to detect a host player's player number. Can't seem to find it, I even tried a backdoor attempt via "Triggering Player" on the Map Init event in the unlikely case that it returns the player number that hosted the game and it returns a -1.

Re: SC2 Editor findings

Posted: Fri Apr 23, 2010 8:10 am
by Ricky_Honejasi
16) Minor thing : On the loading screen, you have the choice to make the user have to hit a key before the game start.

While mostly unwanted for multiplayer maps, it might be very preferable for campaign maps (which you might not want the cinematics/story fire off as soon the big campaign map finishes the load).

In addition, it's easier to have a loading image in SC2 compared to the odd complicated scheme in WC3 that the image was split in 4 that you had to ensure all of them "joined up" correctly. An attachment image shows the loading screen using one of the SC2's internal textures as loading image.

17) To show up images, TGA (common format) and DDS (Textures) are acceptable formats. This implies for a loading image and dialogs (and probably other cases tied to modding).

18) As a slight update for dialogs, you can enforce a dialog to be fully used by any dialog item including an image. An attachment image shows a texture (DDS) off SC2 data using a full dialog in the center of the map.

Re: SC2 Editor findings

Posted: Fri Apr 23, 2010 8:52 am
by Ricky_Honejasi
19) I tried to import a TGA file but it didn't seem to be added into the tree lists either for the loading screen nor for dialog images. I only learned a bit later that you had to save the map first to be available in those tree lists.

Fortunately, it is also possible to backdoor it (if it doesn't show up in the tree list for any reason) by modifying the image path via "custom" (instead of "value" to point to Blizzard files) and writing the following way : "YourImage.tga" (and not YourImage.tga, focus on the "", else it will give you a syntax error).

Two examples shown in an attachment file. One being with correct sizes and such and one that I did let "loop" the image all over on purpose.

20) Another thing I noticed for dialogs, the sizes you input seems to be based on a 1600x1200 full screen resolution regardless of your actual resolution size. If your resolution is lower, it will scale down the image to your resolution. It is probably to minimize issues for mapmakers which instead would have required to make multiple dialog versions for various resolutions.

Side Info) When importing, it's totally NOT recommended to try to import anything from your C: root as folder. Also preferably not from any folder that has too many sub-directories/files.

In such case,  the editor will attempt to make a full tree of your whole folder C: directories/files and essentially will take forever before you even selecting a thing (without to mention trying to navigate through all the tree just for that lone file). Also takes a lot of RAM while it does that. I had to close the editor by force (alt+ctrl+del).

Re: SC2 Editor findings

Posted: Fri Apr 23, 2010 11:24 am
by Ricky_Honejasi
21) You can give new weapons and remove weapons off units via triggers. You cannot add a duplicate of the exact same weapon (as in adding photon cannon weapon twice on a same unit). Thus you need to duplicate the weapon into duplicated types to add those types to mimic multiple weapons of the very same kind.

You can make a weapon fire while a unit is still moving. You can redirect your attack on a unit while stopping but still using the same attack. A unit that auto-fire while moving that way usually tend to fire the closest valid target rather the last target (as soon you re-move after a manual attack, it auto-redirect your fire to others).

Weapons can cost (or gain!) a player's resources or a unit's health/shields/energy to fire. For example, I made a zealot with 3 weapons (that have no shared cooldown between them) to fire a photon cannon-like weapon. Each hit required 1 shields off the zealot and gave me 1 mineral per strike attempt. As the shields went down to 0, the zealot stopped firing. There is an image of it as attachment.

It is also possible to cost a fraction of health, shields or energy. For example setting 0.10 (10%) of shields with zealots of 50 shields would require 5 shields each time it attempts to strike with the weapon.

So ultimately, it would be possible to make some super battlecruisers that would require energy to even shot normally.

Re: SC2 Editor findings

Posted: Sat Apr 24, 2010 2:27 am
by Xenon
I tried making a Phoenix Fire - type behavior that fires at random units. This itself works fine, and can be set to stack, but when the behavior is attached to an item, dropping one of several items will remove the behavior completely.  :P Picking it back up only applies it once; you'll have to drop all the items and pick them back up to get the full effect back.

I managed to make a projectile that will never change its height (this is a weapon, not the behavior described above, I kinda messed up that map by changing specific motion phases values that the editor refuses to reset.)

Re: SC2 Editor findings

Posted: Sat Apr 24, 2010 10:47 am
by Maglok
Just random thoughts.

My initial foray mainly focussed on triggers. I noticed the same issues with terrain, I don't like how water is handled at all.

As for triggers there are really some very interesting things we can 'catch', and I love the library support. I can just write a library of functions to use for a campaign and reuse them easily.

A lot of singleplayer stuff also in it seems. You can toggle story mode with a event.

A conversation has a dialogue tree and usually takes place in story mode, while a transmission is with a portrait somewhere on screen ingame. I made a practice transmission works nicely enough.

Boss health bars are in, very cool. You can have 50 boss health bars max in your map.

You can catch the player after he exits the battle report screen and many other places, like the starmap. IF player enters starmap AND certain variable is set THEN open up mission this or that.

Hell you can create a event based on if the game credits are finished rolling.

Created a nice timer, tricky stuff though without an example.

What I found very interesting was that you can define time as real time or game time. Real time being 5 seconds but game time on fastest being 5 seconds ingame.