SC2Mapster

Compared the current Storm build to the current Void Beta build and discovered a few new things. Mostly small stuff, but somethings are of serious use

Trigger Module

Native Actions/Functions

native void ConversationDataLineSetPlayers (string convId, string lineId, playergroup players); native void ConversationDataLineResetPlayers (string convId, string lineId); native void ConversationDataLineHideForObservers (string convId, string lineId, bool hide);

Part of the conversation system (have not used myself so not very familiar with how it works). This seems to make conversations invisible to observers, reset a conversation, and also make the conversation only occur for certain players, not all.

native void DialogSetPositionRelativeToUnitWithAnchor (int dialog, unit inUnit, string inAttachment, int anchor, int offsetX, int offsetY);

This allows dialogs to be attached to units. Currently this option exists in data with Custom Unit Status Frame field, found in the Unit actor. This adds flexibility, now one can make dialogs appear for units and disappear as needed.

native void PathSetMinimumLinearDistance (int inPathId, fixed inDistance); As the crow flies native fixed PathGetMinimumLinearDistance (int inPathId); As the crow flies native void PathSetMinimumTravelDistance (int inPathId, fixed inDistance); native fixed PathGetMinimumTravelDistance (int inPathId); native void PathSetMinimumStepCount (int inPathId, int inStepCount); native int PathGetMinimumStepCount (int inPathId);

This is for setting the path, the line that shows for orders normally. Now one can use this to easily determine the pathing range that a created path goes.

native int PingCreateWithPlayerId ( playergroup players, string modelLink, point position, color intColor, fixed duration, int player );

Create a ping for players, with option to have the ping originate from a given player.

native int PlayerCommanderLevel (int inPlayer); native void PlayerSetCommanderLevel (int inPlayer, int inCommanderLevel);

Natives for the upcoming Allied Commander mode in Void. Probably Blizzard only commands.

native text UnitGetName (unit inUnit);

Was frankly surprised we didn't have this already, gets the actual name of the unit (which can be different due to name overrides from behaviors).

const int c_unitStateDazed = 35;

New status for units, unknown what it implicitly does

Map Tags native string PickedExclusiveMapTag ();

Unknown.

Actors

Unit Ring

New actor, unknown what it does.

Data

DSP

CustomCompressor

New DSP type, fields are below

AttackMs
ReleaseMs
ThresholdDB
Ratio
MakeUpGainDB

SoundMixSnapshot

New Data Type, fields are below

Attack
Delay
Flags
Hold
MixGlobal
MixLocal
MixNonLocal
Release

Abilities

Effect

Reapproachable - new flag, unknown what it does

Behavior

Buff

Reveal Unit - Possibly specifies the unit to reveal when this behavior is applied.

Effects

Remove Behavior

ExcludeOriginPlayer ExcludeCasterUnit RequireOriginPlayer RequireCasterUnit

New fields. Possible conditional removal of behaviors based on caster?

Model

VariationPreload

New flag, preloads all variations

Validators

Compare Behavior Count

ExcludeOriginPlayer ExcludeCasterUnit RequireOriginPlayer RequireCasterUnit

Same as found in remove behavior

Weapon

TeleportResetRange

Range a unit has to teleport before target acquisition is lost?

UI Changes

Going to paste the raw XML here.

<!-- Wizard dialog -->
<window label="WizardDialog">
    <size>600,400</size>
    <minsize>400,200</minsize>
    <centerInParent/>
    <cancelButton/>

    <control label="BackButton">
        <pos>295,25</pos>
        <size>90,21</size>
        <posReverseX/>
        <posReverseY/>
        <text>EDSTR_WIZARDDIALOG_BACK</text>
    </control>

    <control label="NextButton">
        <pos>195,25</pos>
        <size>90,21</size>
        <posReverseX/>
        <posReverseY/>
        <text>EDSTR_WIZARDDIALOG_NEXT</text>
    </control>

    <control label="CancelButton">
        <size>90,20</size>
        <pos>95,25</pos>
        <posReverseX/>
        <posReverseY/>
        <text>EDSTR_WIZARDDIALOG_CANCEL</text>
    </control>
    
    <control label="PageText">
        <pos>6,20</pos>
        <size>300,16</size>
        <autoResizeX/>
        <posReverseY/>
    </control>

    <control label="Panes">
        <pos>2,2</pos>
        <size>2,32</size>
        <autoResizeX/>
        <autoResizeY/>
        <value label="PaneMinSizeInputs">150</value>
        <value label="PaneMinSizeErrors">100</value>
    </control>

    <control label="PanesWithErrorText">
        <pos>2,2</pos>
        <size>2,54</size>
        <autoResizeX/>
        <autoResizeY/>
    </control>

    <control label="ErrorText">
        <pos>2,52</pos>
        <size>82,18</size>
        <autoResizeX/>
        <posReverseY/>
    </control>

    <control label="ErrorShowCheckbox">
        <pos>80,50</pos>
        <posReverseX/>
        <posReverseY/>
        <text>EDSTR_WIZARDDIALOG_SHOWERRORS</text>
    </control>

    <control label="ErrorList">
        <pos>0,0</pos>
        <size>0,0</size>
        <autoResizeX/>
        <autoResizeY/>
    </control>

    <control label="InputContainer">
        <pos>0,0</pos>
        <size>0,0</size>
        <autoResizeX/>
        <autoResizeY/>
    </control>

    <value label="MinColWidth">100</value>
    <value label="InputBaseHeight">20</value>
    <control label="InputLabel">
        <pos>2,2</pos>
        <size>2,16</size>
        <autoResizeX/>
    </control>

    <!-- Checkbox -->
    <value label="InputCheckboxHeight">20</value>
    <control label="InputCheckbox">
        <pos>2,2</pos>
    </control>

    <!-- Menu -->
    <value label="InputMenuHeight">43</value>
    <control label="InputMenu">
        <pos>2,20</pos>
        <size>2,21</size>
        <autoResizeX/>
        <options>textWidthCap</options>
    </control>

    <!-- Radio Group -->
    <control label="InputRadioGroup">
        <pos>2,20</pos>
        <size>2,18</size>
        <autoResizeX/>
    </control>

    <!-- Text -->
    <value label="InputTextHeight">20</value>
    <control label="InputText">
        <pos>2,2</pos>
        <size>2,16</size>
        <autoResizeX/>
    </control>
    
    <!-- Detail -->
    <control label="InputDetailArea">
        <pos>2,20</pos>
        <size>2,2</size>
        <autoResizeX/>
        <autoResizeY/>
    </control>
</window>

<menu label="ObjectEditor.WizardsCreate">
    <wizardsCreate/>
</menu>

<menu label="ObjectEditor.WizardsLoad">
    <wizardsLoad/>
</menu>

<menu label="ObjectEditor.Wizards">
    <item><text>EDSTR_MENU_WIZARDSCREATE</text>             <submenu>ObjectEditor.WizardsCreate</submenu>   </item>
    <item><text>EDSTR_MENU_WIZARDSLOAD</text>               <submenu>ObjectEditor.WizardsLoad</submenu>     </item>
    <item><separator/>                                                                                      </item>
    <item><text>EDSTR_MENU_CREATEWIZARD</text>              <command>ObjEdWizardCreate</command>            </item>
    <item><text>EDSTR_MENU_MANAGEWIZARDS</text>             <command>ObjEdWizardManage</command>            </item>
</menu>

This appears to be the data spaces I noted in my earlier thread. This appears to be a wizard for data objects. Based on the XML, it appears you can select data fields and create a customized look to the editor, thus replicating the WC3 object editor. However, in this case, you will still have the other data entries pre populated and hidden, and here we can select which fields to show or not.

This will have a fair amount of upfront work, because one has to cull which data fields they want to use, but there appears to be the option to export and import such "wizards" and thus advanced users can create templates with objects already linked and all (or at least the objects will be linked in the background) and hand them off to less advanced users to more easily create stuff in the editor, streamlining a great deal of production.

<!--<mbitem><mbtext>EDSTR_MENU_WIZARDS</mbtext>     <mbmenu>ObjectEditor.Wizards</mbmenu>   </mbitem>-->

However it appears this is a feature in progress, since it is not enabled yet (the menu is hidden currently in the Heroes editor).

General Preferences

Small changes here but can be very useful.

Break On Start

This will allow one to set a map to auto break (breakpoint) their map script at map start, before any triggers run. This can be useful since you can then have time to setup breakpoints for map initialization scripts, and more accurately trace how the map loads up.

Miscellaneous Files

Editor Data

    <!-- Start Location Footprint used for start location placement snapping -->
    <StartLocationFootprint><Value>StormPlacementFootprint1x1</Value></StartLocationFootprint>
    
    <!-- DefaultMap - Default settings for creating a new map -->
    <DefaultMap>
        <Size>              <Value>128,128</Value>              </Size>
        <TexSet>            <Value>StormKingsCrestGardens</Value> </TexSet>
        <Texture>           <Value>StormCastleWorld6</Value>      </Texture>
        <Height>            <Value>8</Value>                    </Height>
        <HeightMargin>      <Value>0.5</Value>                  </HeightMargin>
        <RandomHeight>      <Value>0</Value>                    </RandomHeight>
        <RandomStrength>    <Value>50</Value>                   </RandomStrength>
        <RandomPersistency> <Value>50</Value>                   </RandomPersistency>
    </DefaultMap>

This was added in Storm, which will be the default map settings when creating a new map. Since they have this configured, certainly points to maturity (and daresay, release) of the editor.

That's all for now, I'll update if I find anything else of note.

Interesting read, thanks for sharing.

So, player chat can be altered with these conversation commands? As in, for example, block chatting with enemies, prevent players from chatting with player #, etc?

I wonder if they added radial distribution for periodic effects in persistent? Something that i thought they will wanna do.

Quote from ArcaneDurandel: Go

However it appears this is a feature in progress, since it is not enabled yet (the menu is hidden currently in the Heroes editor).

wait, heroes does have an editor?

@FunkyUserName: Go

Internally, yes. It differs from the SC2 editor enough to be a seperate one. Hence the current different builds.

@willuwontu: Go

The editor is not in the beta nor in storm, however the files used by the game are, and that is what I'm analyzing. Furthermore, the core dependency includes the XML files that are used to describe the editor (what menu goes where, what is in that menu, and so on). Since it is the same engine, the file structure of the data is mostly the same, allowing a simple comparison between the two.

TL;DR: The editors are not shipped with the games, the files they use are (and it would be too big of a hassle for Blizzard to remove them, so there you go).

I'm not sure I understand what this is about. Could you explain a bit? Thanks.

@finiteturtles: Go

Normally, when you issue orders, it creates a line/path from the caster to the target point. This also happens a bit for when you queue up commands or set rally points. Now this does not always display, and usually doesn't display for your enemies. But sometimes you WANT it to be seen by your enemies (perhaps to mark which path they decided to take, and so you can react accordingly). It appears you now get the distance such pathing will take, and even set the max distance such a path will display for (perhaps you only want to show the path to enemies up to a point, not the entire way).

For most targeted abilities, this path appearance is controlled by the Orders field, which lets you set the color, texture, and scale for the line, and the model to use for the actual target point.

Another application of this is to show projectiles targeting, so you can perhaps aim abilities that intercept projectiles

THe difference between the trigger based path display and the orders field is that the path display shows the ACTUAL path the unit will take, instead of what the order is. Order just does direct line (as the crow flies), whereas path display will show the path the unit will really take.

This can be useful for timing waves in games, since with the pathing display, you can get a better idea of how the units behave en route.

thanks for the explanation.