In your scripts you can now use the following syntax for the extensions:
JASS:
//! external FileImporter { hard_drive_file_path target_path_in_map }
//! external ObjectMerger w3o_file_on_hard_drive { more_w3o_files_of_same_type }
//! external PathMapper tile_list | check_flag apply_flag [check_mode] [apply_mode]
FileImporter examples:
JASS:
//! external FileImporter images\icon1.blp CommandButtons\BTNIcon1.blp
//! external FileImporter D:\war3\images\icon2.blp CommandButtons\BTNIcon2.blp icon3.blp CommandButtons\BTNIcon3.blp
Relative paths to the folders defined in [lookupfolders] in mapcompiler.conf
and the folder, where the map is, are automatically resolved.
For better performance you can import more than one file per call, like seen in the second example.
The imported file list gets correctly updated, so after reloading the map you can see the files in the import manager.
It's mainly useful for distributing systems that require files.
ObjectMerger examples:
JASS:
//! external ObjectMerger my_items.w3t
//! external ObjectMerger my_abilities.w3a D:\war3\more_abilities.w3a even_more_abilities.w3a
//! external ObjectMerger objects\units.w3u
Relative paths to the folders defined in [lookupfolders] in mapcompiler.conf
and the folder, where the map is, are automatically resolved.
You can merge as many files of the same type as you wish, like in the second example.
Allowed object types are w3u, w3t, w3b, w3d, w3a, w3h and w3q.
All files of one call must have the same type, you can't mix w3u and w3a for example.
This is used to distribute systems that require object editor data.
Use the export function of WE to create files that can be merged,
using an MPQ viewer to extract those files is bad because it won't resole TRIGSTR references.
You'll have to close and reopen your map to see the imported data in the object editor.
This one requires VB 6 runtime files (
http://www.wc3campaigns.net/tools/weu/RuntimeFiles.exe)
The tool is also capable of id renaming as seen in the Widgetizer before.
An ability with the name Lightning Bolt::Albt for example will be imported with the id 'Albt'. Its name will be changed to just Lightning Bolt.
PathMapper examples:
JASS:
//! external PathMapper LdrtLgrsLgrd 2 |
//! external PathMapper Ldrt 40 !
The first example makes the map unwalkable where Lordaeron Dirt, Lordaeron Grass or Lordaeron Dark Grass is.
The second example sets the pathing to normal ground where tiles other than Lordaeron Dirt are.
You can look up the tile-ids in TerrainArt\Terrain.slk which can be extracted from War3Patch.mpq.
To be able to use this you will need the following flags table and a few examples:
Code:
0x01: unused
0x02: 1=no walk 0=walk ok
0x04: 1=no fly 0=fly ok
0x08: 1=no build 0=build ok
0x10: unused
0x20: 1=blight 0=normal
0x40: 1=no water 0=water
0x80: 1=unknown unpathable 0=normal
00 bridge doodad
08 shallow water
0A deep water
40 normal ground
48 water ramp, unbuildable grounds, unbuildable parts of doodads
CA cliff edges, solid parts of doodads
CE map boundaries
As you can see the parameter after the tilelist is the flag value and then there's a paramter to
change the check mode and/or the apply mode. Apply modes can be:
- |: binary or
- &: binary and
- ^: binary xor
So in the first example only the no-walk-bit is set with a binary or and nothing else is changed.
If you don't specify an apply mode, the old values are completely replaced by the value you specify.
Like in the second example where it's set to normal ground. Check modes here can be:
In the second example ! is used to change the pathing for all tiles that are NOT in the list.
If you don't set this parameter the normal mode will apply the change for all tiles in the list.
JASS:
//! external PathMapper CE FD 1 &
//! external PathMapper A F5 0 &
It's also possible to update the path map independant of the tiles.
In the above examples the current pathing value of each point is compared to a mask (the first parameter).
The second parameter again is the new flag value that will be applied. In this case the following check modes are available:
- 1: all bits that are set in the mask must be set for a point to be updated, other flags may be set too
- 0: all bits that are set in the mask can be set, but don't have to, other flags must not be set for a point to be updated
The default check mode is that the pathing value of a point must exactly match the specified mask
in order to have the change applied. Change modes are like above and, or, xor, or set by default.
In example one map boundaries are made walkable by removing the no-walk-bit with a binary and.
In the second example areas that have either the no-walk or the no-fly bit set, are made walkable and flyable.
) with a short reply from PitzerMike. I have to admit I didn't understand it 100%, but it said this: