Extended presence flags/Track Tutorial
- Extended presence flags
- Related articles
- LE-CODE: FAQ for track creators
- LE-CODE: Distribution Tutorial
- LE-CODE: FAQ for distribution creators
- LEX: File format and definitions
- Wiimm's Test Tracks
- Related Categories
.png){kind=logo}
This page is directed to track editors. It describes how to use the new features of the Extended presence flags (XPF).
Introduction
At the moment, Wiimms SZS Tools are the only tools that support the use of the Extended presence flags with special commands. But it is worse. Almost all other tools destroy the extended values by partially resetting the values to zero. Wiimms SZS Tools offer a solution for this: Repairing the KMP after an edit.
For these reasons, all examples here come from Wiimms Tools, v2.14a or later is required.
In general, you extract a SZS with auto-decode, edit the KMP text file, and re-create the SZS (KMP is compiled automatically). While editing, you add commands like »$ENABLE IF$ONLINE« or »$DISABLE IF$OFFLINE« below the object definition. Both commands looks identical, and for LE-CODE they are identical. But for standard code, the first object is disabled (will be enabled by LE-CODE under conditions) and the second one is enabled. So you have full control for both sides of the world (with and without LE-CODE).
First steps with predefined conditions
The following examples show situations with 2 or 3 variants. One of these variants is always defined using DISABLE — this object variant is used with standard code. All others are defined using ENABLE and are ignored by standard code. Only through LE-CODE are the objects disabled or enabled based on the conditions.
→ Technical Description: Predefined conditions
Example: Standard or LE-CODE only
First, we setup an object, that is used in standard code only, but disabled with LE-CODE. For this, we add »$DISABLE if$lecode« directly below the object definition:
#------------------------------------------------------------------------------------ o1 o$itembox v3(1000) 0 0 0 0 -1 0 v3(0) 0 0 0 0 0x3f v3(1) $DISABLE if$lecode #------------------------------------------------------------------------------------
Now we change the object definition, so that it is active only with LE-CODE, but not used by standard code:
#------------------------------------------------------------------------------------ o2 o$itembox v3(2000) 0 0 0 0 -1 0 v3(0) 0 0 0 0 0x3f v3(1) $ENABLE if$lecode #------------------------------------------------------------------------------------
Both (standard code only and LE-CODE only) can be combined:
#------------------------------------------------------------------------------------ o1 o$itembox v3(1000) 0 0 0 0 -1 0 v3(0) 0 0 0 0 0x3f v3(1) $DISABLE if$lecode #------------------------------------------------------------------------------------ o2 o$itembox v3(2000) 0 0 0 0 -1 0 v3(0) 0 0 0 0 0x3f v3(1) $ENABLE if$lecode #------------------------------------------------------------------------------------
If using Wiimms SZS Tools to create a KMP text file, the relevant piece of text looks like this:
#------------------------------------------------------------------------------------
# o$itembox, S1234-678, no route, solid, found in tracks + arenas + other files
# Extended presence flags, mode 1
o1 0x65 1000.000 1000.000 1000.000 0 0 0 0 -1
> 0x1000 0.000 0.000 0.000 0 0 0 0 0x103f
> 1.000 1.000 1.000
$DISABLE IF$LECODE # lecode
#------------------------------------------------------------------------------------
# o$itembox|0x1000, S1234-678, no route, solid, found in tracks + arenas + other files
# |0x1000 => Disabled object. Conditional enabled by LE-CODE.
# Extended presence flags, mode 1
o2 0x1065 2000.000 2000.000 2000.000 0 0 0 0 -1
> 0x1001 0.000 0.000 0.000 0 0 0 0 0x103f
> 1.000 1.000 1.000
$ENABLE IF$LECODE # lecode
#------------------------------------------------------------------------------------
Example: Offline/Online
For this example we use GCN Bowser's Castle (Tock). There are problems with the synchronization between Bowser and Fireballs. The time offset is different offline than online. So Tock released two versions, one for offline and one for online. Distributions had to choose a version.
So he declared 2 different sets of object VolcanoBall1. For offline it is:
#------------------------------------------------------------------------------------
o52 0xd6 -58936.000 14023.287 34958.801 132 158 496 124 r19
> 0 0.000 0.000 0.000 0 0 0 0 0x3f
> 1.600 1.600 1.600
#------------------------------------------------------------------------------------
The Online setup differs in settings 2 and 4:
#------------------------------------------------------------------------------------
o52 0xd6 -58936.000 14023.287 34958.801 132 329 496 248 r19
> 0 0.000 0.000 0.000 0 0 0 0 0x3f
> 1.600 1.600 1.600
#------------------------------------------------------------------------------------
A combined version with the extended presence flags looks like this:
#------------------------------------------------------------------------------------
o52 0xd6 -58936.000 14023.287 34958.801 132 158 496 124 r19
> 0 0.000 0.000 0.000 0 0 0 0 0x3f
> 1.600 1.600 1.600
$ENABLE if$offline
#------------------------------------------------------------------------------------
o52 0xd6 -58936.000 14023.287 34958.801 132 329 496 248 r19
> 0 0.000 0.000 0.000 0 0 0 0 0x3f
> 1.600 1.600 1.600
$DISABLE if$offline
#------------------------------------------------------------------------------------
The commands »$DISABLE« and »$ENABLE« will modify the object id (flag x01000), the reference id (padding) and the presence flags (MODE=1) of the previous defined object. The default for standard code are the online timings.
The condition »if$offline« is only an example. You can use any of these conditions, simply add »if$« in front of the name or alias. Conditions for the engine classes and random scenarios are defined by parser functions »if$engine(...)« and »if$random(...)« (see below). More complex conditions are explained in own sections below.
If using Wiimms SZS Tools to create a KMP text file, the relevant piece of text looks like this:
#------------------------------------------------------------------------------------
# o$VolcanoBall1|0x1000, S1234----, route needed, solid, found in tracks
# |0x1000 => Disabled object. Conditional enabled by LE-CODE.
# Extended presence flags, mode 1
o52 0x10d6 -58936.000 14023.287 34958.801 132 158 496 124 r19
> 0x1004 0.000 0.000 0.000 0 0 0 0 0x103f
> 1.600 1.600 1.600
$ENABLE IF$OFFLINE # offline
#------------------------------------------------------------------------------------
# o$VolcanoBall1, S1234----, route needed, solid, found in tracks
# Extended presence flags, mode 1
o52 0xd6 -58936.000 14023.287 34958.801 132 329 496 248 r19
> 0x1005 0.000 0.000 0.000 0 0 0 0 0x103f
> 1.600 1.600 1.600
$DISABLE IF$OFFLINE # offline
#------------------------------------------------------------------------------------
Example: Engine Classes
→ Technical Description: Engine Selection
Many objects support different timings for 50cc, 100cc and 150cc, but not for 200cc. LE-CODE doesn't support 200cc yet, but it is planned. So alternative objects are needed to support alternative timings.
In the examples above a 2-way switch (standard or LE-CODE, offline or online) has been implemented, but here a 3-way switch will be demonstrated. So we divide the engine classes into the 3 groups 50cc+100cc(+battle), 150cc (incl mirror) and 200cc (incl mirror). Wiimms SZS Tools provide the following symbols to make definitions more readable:
- EN$BATTLE, EN$50, EN$100, EN$150 and EN$200 for standard modes.
- EN$150M and EN$200M for mirror modes.
- EN$150X as short cut for EN$150,EN$150M.
- EN$200X as short cut for EN$200,EN$200M.
- EN$MIRROR as short cut for EN$150M,EN$200M.
A negative index deselects an engine mode. »*« is a short cut for all modes.
A typical definition looks like this:
#------------------------------------------------------------------------------------ # Enable for all engines modes except 150cc + 200cc + both mirror modes o1 o$itembox v3(1000) 0 0 0 0 -1 0 v3(0) 0 0 0 0 0x3f v3(1) $ENABLE if$engine(*,-EN$150X,-EN$200X) #------------------------------------------------------------------------------------ # Disable if engines mode is not 150cc (or its mirror) # This is the default itembox if not using LE-CODE o2 o$itembox v3(2000) 0 0 0 0 -1 0 v3(0) 0 0 0 0 0x3f v3(1) $DISABLE if$engine(*,-EN$150X) #------------------------------------------------------------------------------------ # Enable if engines mode is 200cc (or its mirror) o3 o$itembox v3(3000) 0 0 0 0 -1 0 v3(0) 0 0 0 0 0x3f v3(1) $ENABLE if$engine(EN$200X) #------------------------------------------------------------------------------------
Here we have 1 $DISABLE and 2 $ENABLE objects. The DISABLE one is the object, that is used by standard code.
If using Wiimms SZS Tools to create a KMP text file, the relevant piece of text looks like this:
#------------------------------------------------------------------------------------
# o$itembox|0x1000, S1234-678, no route, solid, found in tracks + arenas + other files
# |0x1000 => Disabled object. Conditional enabled by LE-CODE.
# Extended presence flags, mode 1
o1 0x1065 1000.000 1000.000 1000.000 0 0 0 0 -1
> 0x1e07 0.000 0.000 0.000 0 0 0 0 0x103f
> 1.000 1.000 1.000
$ENABLE if$engine(en$battle,en$50,en$100) # if selected engines are active
#------------------------------------------------------------------------------------
# o$itembox, S1234-678, no route, solid, found in tracks + arenas + other files
# Extended presence flags, mode 1
o2 0x65 2000.000 2000.000 2000.000 0 0 0 0 -1
> 0x1e28 0.000 0.000 0.000 0 0 0 0 0x103f
> 1.000 1.000 1.000
$DISABLE if$engine(en$battle,en$50,en$100,en$200,en$200m) # if selected engines are active
#------------------------------------------------------------------------------------
# o$itembox|0x1000, S1234-678, no route, solid, found in tracks + arenas + other files
# |0x1000 => Disabled object. Conditional enabled by LE-CODE.
# Extended presence flags, mode 1
o3 0x1065 3000.000 3000.000 3000.000 0 0 0 0 -1
> 0x1e50 0.000 0.000 0.000 0 0 0 0 0x103f
> 1.000 1.000 1.000
$ENABLE if$engine(en$200,en$200m) # if selected engines are active
#------------------------------------------------------------------------------------
Example: Random Scenarios
→ Technical Description: Random Scenarios
A complete other idea are random scenarios. It allows you to change the track layout in up to 8 different ways. Therefore the LE-CODE executor creates a random number between 1 and 8. If playing online, it is guaranteed, that all players use the same number.
In our example we want to setup 3 random scenarios with equal probability, and the first scenario should be used by standard code. Unfortunately only 8 scenarios with 12.5% each are available. So we setup 3 objects 25% + 37.5% + 37.5%. As object we use a Wiggler, that should walk on different routes:
#------------------------------------------------------------------------------------
# o$hanachan, S1-------, route needed, solid, found in tracks
o1 0xe2 -12000.000 60000.000 -22200.000 30 0 0 0 r1
> 0 0.000 0.000 0.000 0 0 0 0 0x3f
> 1.000 1.000 1.000
$DISABLE if$random(3,4,5,6,7,8)
#------------------------------------------------------------------------------------
# o$hanachan, S1-------, route needed, solid, found in tracks
o2 0xe2 -12000.000 60000.000 -22200.000 30 0 0 0 r2
> 0 0.000 0.000 0.000 0 0 0 0 0x3f
> 1.000 1.000 1.000
$ENABLE if$random(3,4,5)
#------------------------------------------------------------------------------------
# o$hanachan, S1-------, route needed, solid, found in tracks
o3 0xe2 -12000.000 60000.000 -22200.000 30 0 0 0 r3
> 0 0.000 0.000 0.000 0 0 0 0 0x3f
> 1.000 1.000 1.000
$ENABLE if$random(6,7,8)
#------------------------------------------------------------------------------------
Here again, we have one $DISABLE and two $ENABLE objects. The disable one is the object, that is used by standard code.
Definition objects
→ Technical Description: Definition Objects
Definition objects of type Bits were defined and implemented before Wiimm had the idea with predefined conditions — they are much easier to handle. In a third definition phase Wiimm defined logical OR and AND combinations of predefined conditions. Anyway, there are only some complex conditions where definition objects are really needed. This is the case if a combination of conditions is needed. The 3 types of definition objects are:
- Bit based conditions, where each bit represents a combination of a game mode, offline or online, and the number of players.
- Logical OR combinations of predefined conditions: It returns true if at least one condition is true.
- Logical AND combinations of predefined conditions: It returns true if all conditions are true.
In our example we want to distinguish between:
- Online AND ≥2 humans at Wii AND engine class 150cc or 200cc.
- And the opposite with: Offline OR 1 player at Wii OR engine class <150cc.
Here 3 different solutions are provided, 1 for each definition object type.
Definition by BITS
→ Technical Description: Definition Objects of type BIT
This mode is called »BIT« mode, because each of the 128 bits of the 8 settings has an own meaning. The bit is addressed by game mode, offline or online and number of players [bits] .
First we define an definition object and then two real objects. But the order is irrelevant. For the BITS definition any id between 0x2000 and 0x2fff can be used:
#------------------------------------------------------------------------------ $DEFOBJ-RACE 0x2000, c$online & c$p234 $ENABLE if$engine(en$150x,en$200x) #------------------------------------------------------------------------------ o21 o$itembox v3(1) 0 0 0 0 -1 0 v3(0) 0 0 0 0 0x3f v3(1) $DISABLE-BY-NOT 0x2000 #------------------------------------------------------------------------------ o22 o$itembox v3(2) 0 0 0 0 -1 0 v3(0) 0 0 0 0 0x3f v3(1) $ENABLE-BY-NOT 0x2000 #------------------------------------------------------------------------------
If using Wiimms SZS Tools to create a KMP text file, the relevant piece of text looks like this:
#------------------------------------------------------------------------------------
# Definition object type RACE. Param: obj_id, versus, itemrain
# Meaning of the conditions:
# */0x2aa0: Online race with 2 human players at Wii.
# */0x8000: Reserved 2.
# It is used by 2 regular objects.
$DEFOBJ-RACE 0x2000, 0xaaa0
$ENABLE if$engine(en$150,en$200,en$150m,en$200m) # if selected engines are active
#------------------------------------------------------------------------------------
# o$itembox, S1234-678, no route, solid, found in tracks + arenas + other files
# Extended presence flags, mode 1
o21 0x65 1.000 1.000 1.000 0 0 0 0 -1
> 0x2000 0.000 0.000 0.000 0 0 0 0 0x113f
> 1.000 1.000 1.000
$DISABLE-BY-NOT 0x2000
#------------------------------------------------------------------------------------
# o$itembox|0x1000, S1234-678, no route, solid, found in tracks + arenas + other files
# |0x1000 => Disabled object. Conditional enabled by LE-CODE.
# Extended presence flags, mode 1
o22 0x1065 2.000 2.000 2.000 0 0 0 0 -1
> 0x3000 0.000 0.000 0.000 0 0 0 0 0x103f
> 1.000 1.000 1.000
$ENABLE-BY-NOT 0x2000
#------------------------------------------------------------------------------------
Definition by OR operator
→ Technical Description: Definition Objects of type OR
And again we define an definition object and then two real objects. And again the order is irrelevant. For the OR definition any id between 0x4000 and 0x4fff can be used:
#------------------------------------------------------------------------------ $DEFOBJ-OR 0x4000, if$offline, if$p1, if$engine(en$battle,en$50,en$100) #------------------------------------------------------------------------------ o41 o$itembox v3(1) 0 0 0 0 -1 0 v3(0) 0 0 0 0 0x13f v3(1) $DISABLE-BY 0x4000 #------------------------------------------------------------------------------ o42 o$itembox v3(2) 0 0 0 0 -1 0 v3(0) 0 0 0 0 0x3f v3(1) $ENABLE-BY 0x4000 #------------------------------------------------------------------------------
If using Wiimms SZS Tools to create a KMP text file, the relevant piece of text looks like this:
#------------------------------------------------------------------------------------
# Definition object type OR. Param: obj_id, condition_1 [,conditions_2_8]...
# It is used by 2 regular objects.
$DEFOBJ-OR 0x4000, IF$OFFLINE, IF$SINGLE, if$engine(en$battle,en$50,en$100)
#------------------------------------------------------------------------------------
# o$itembox, S1234-678, no route, solid, found in tracks + arenas + other files
# Extended presence flags, mode 1
o41 0x65 1.000 1.000 1.000 0 0 0 0 -1
> 0x5000 0.000 0.000 0.000 0 0 0 0 0x113f
> 1.000 1.000 1.000
$DISABLE-BY 0x4000
#------------------------------------------------------------------------------------
# o$itembox|0x1000, S1234-678, no route, solid, found in tracks + arenas + other files
# |0x1000 => Disabled object. Conditional enabled by LE-CODE.
# Extended presence flags, mode 1
o42 0x1065 2.000 2.000 2.000 0 0 0 0 -1
> 0x4000 0.000 0.000 0.000 0 0 0 0 0x103f
> 1.000 1.000 1.000
$ENABLE-BY 0x4000
#------------------------------------------------------------------------------------
Definition by AND operator
→ Technical Description: Definition Objects of type AND
Finnaly we use an AND definition. For it any id between 0x6000 and 0x6fff can be used:
#------------------------------------------------------------------------------ $DEFOBJ-AND 0x6000, if$online, if$p234, if$engine(en$150x,en$200x) #------------------------------------------------------------------------------ o61 o$itembox v3(1) 0 0 0 0 -1 0 v3(0) 0 0 0 0 0x13f v3(1) $DISABLE-BY-NOT 0x6000 #------------------------------------------------------------------------------ o62 o$itembox v3(2) 0 0 0 0 -1 0 v3(0) 0 0 0 0 0x3f v3(1) $ENABLE-BY-NOT 0x6000
If using Wiimms SZS Tools to create a KMP text file, the relevant piece of text looks like this:
#------------------------------------------------------------------------------------
# Definition object type AND. Param: obj_id, condition_1 [,conditions_2_8]...
# It is used by 2 regular objects.
$DEFOBJ-AND 0x6000, IF$ONLINE, IF$MULTI, if$engine(en$150,en$200,en$150m,en$200m)
#------------------------------------------------------------------------------------
# o$itembox, S1234-678, no route, solid, found in tracks + arenas + other files
# Extended presence flags, mode 1
o61 0x65 1.000 1.000 1.000 0 0 0 0 -1
> 0x6000 0.000 0.000 0.000 0 0 0 0 0x113f
> 1.000 1.000 1.000
$DISABLE-BY-NOT 0x6000
#------------------------------------------------------------------------------------
# o$itembox|0x1000, S1234-678, no route, solid, found in tracks + arenas + other files
# |0x1000 => Disabled object. Conditional enabled by LE-CODE.
# Extended presence flags, mode 1
o62 0x1065 2.000 2.000 2.000 0 0 0 0 -1
> 0x7000 0.000 0.000 0.000 0 0 0 0 0x103f
> 1.000 1.000 1.000
$ENABLE-BY-NOT 0x6000
#------------------------------------------------------------------------------------
Test all scenarios by simulation
Due to the conditional objects, a track looks different depending on the condition. Each of these variants is called a scenario (not to be confused with a random scenario).
LE-CODE now offers authors or track testers the opportunity to test each of these scenarios, offline and on their own. A tester therefore does not need 12 players online to test a 12-player scenario. Instead, a simulation is activated via LEX section TEST. The simulations cover not only LE-CODE support. It is also possible to simulate the behavior of standard code for 1, 2 or 3+4 players (scenarios provided by standard presence flags). Wiimms SZS Tools offer the option of displaying all different scenarios or creating duplicates of the route with automatically created simulation parameters. Manual setting of the simulation parameters is of course also possible.
A tester can …
- … list all possible scenarios of a track.
- … duplicate the track for each scenario of a track.
- … manually define simulation settings.
- … remove all simulation settings.
List all scenarios
With the following commands you can list all different scenarios of a track:
wkmpt gamemodes TRACK.szs wkmpt gamemodes course.kmp wkmpt gamemodes course.kmp.txt
You can use gm aa short cut for command gamemodes.
All commands analyze the presence flags combinations with and without extension support and print a list of scenarios. The lists consists of index, scenario version and scenario name. Scenario versions are only equal, if the scenarios are duplicates. Duplicates happens only, if --gamemodes option TT or FULL is set. Option --long (short: -l) enables additional information. See szs.wiimm.de for details.
The following example shows the analysis of Daisy Circuit:
File KMP:senior_course.szs/./course.kmp 1. 1 V1+ # Versus offline, 1 player @Wii, relevant for standard code 2. 2 V2+ # Versus offline, 2 players @Wii, relevant for standard code 3. 3 V3+ # Versus offline, 3 players @Wii, relevant for standard code 107 objects analyzed in 34us: 3 different scenarios total (3 standard code, 3 extended code).
The comment behind »#« were added manually and are not part of the listing. Daisy Circuit uses standard presence flags to distinguish between 1, 2 and 3+4 players. So the list contains 3 members V1, V2 and V3 for Versus N. V4 is possible, but here the same as V3. The plus sign means, that the scenario is relevant for standard code too. No online scenarios are listed. That means, that the online scenarios are already covered by the offline scenarios.
Another example with GCN Bowser's Castle (Tock):
File KMP:GCN Bowser's Castle v1.3.2.rot (Tock).szs/./course.kmp 1. 1 V1 # Versus offline, 1 player @Wii 2. 2 V2 # Versus offline, 2 players @Wii 3. 3 V1,2+ # Versus online, 1 player @Wii, 2-6 players total, standard code 4. 4 V2,2+ # Versus online, 2 players @Wii, 2-6 players total, standard code 70 objects analyzed in 31us: 4 different scenarios total (2 standard code, 4 extended code).
Here online and offline are distinguished and standard code works like online. Onle the range for 2-6 players online is listed. This means, that scenarios with more than 6 players are covered by other scenarios.
If using --gamemode full you get a complete list:
Listing
The second column tells the scenario index. You can see, that only 4 really different scenarios exists. If a track includes objects, that depend on engine class and random scenario, then up to 1573 different scenarios are possible.
Option --gamemodes
???
szs.wiimm.de for details.
Duplicate a track to simulate all scenarios
???
wszst duplicate TRACK.szs DEST_NAME.szs
Manage LEX:TEST manually
???
Tools wszst and wlect allow to create and clean this section by options.
wszst patch TRACK.szs --lt-* wlect patch course.lex --lt-*
Clean LEX:TEST manually
Before releasing a track, you have to remove the simulation parameters. You can do it manually by removing file course.lex from the tracks's SZS. An alternative is to use the pacth command with option --lt-clear (lt is an abbreviation of LEX:TEST):
wszst patch --lt-clear TRACK.szs wszst patch --lt-clear TRACK.szs -od CLEAN_TRACKS.szs
The first command clears TRACK.szs in place, the second command creates a new cleaned track file.
KMP Editors
It is a pity that most tools have problems with the padding and just ignore it. Usually an edit tool should not change unknown data and then save it again. And for games like Mario Kart Wii, such data should at least be displayed → Details
For this reason, Wiimm implemented a repairing feature in his SZS Tools. The following steps are provided:
- Use Wiimms SZS Tools to edit KMP section GOBJ:
- Edit KMP with your favorite KMP editor.
- Fix the KMP with wszst patch --repair-xpf (see next section). Repeat this step after every KMP edit.
Fix KMP after edit
Here are some variants how to repair a KMP. It is possible to repair a standalone KMP or a KMP as part of a tracks' SZS file. The template file defined by option --repair-xpf can be a KMP file or a tracks' SZS file too. The main idea is, that the edited (and broken) KMP is scanned, and missing padding values are fixed by the related object of the template file. Therefore the object order is important.
Edits by KMP Cloud and by KMP Modifier can not be repaired, because they destroy the object-id too.
wszst patch "CURRENT.szs" -od "NEW.szs" --repair-xpf "PREVIOUS.szs" wszst patch "CURRENT.szs" -od "NEW.szs" --repair-xpf "PREVIOUS.kmp" wszst patch "CURRENT.szs" -od "NEW.szs" --repair-xpf "PREVIOUS.kmp.txt" wszst patch "CURRENT.kmp" -od "NEW.kmp" --repair-xpf "PREVIOUS.szs" wszst patch "CURRENT.kmp" -od "NEW.kmp" --repair-xpf "PREVIOUS.kmp" wszst patch "CURRENT.kmp" -od "NEW.kmp" --repair-xpf "PREVIOUS.kmp.txt"
- CURRENT
- This is either a SZS or a KMP file after editing by another tool, that destroys the extended presence flags.
- NEW
- This the new fixed file, that will be created. It is either a SZS or a KMP file, but of same type as CURRENT. If -od NEW.szs is omitted, CURRENT is overwritten.
- PREVIOUS
- This the (readonly) template file, that is used to repair CURRENT. The type is either SZS, KMP binary or KMP text.
- --repxpf
- A short cut for --repair-xpf.
If you have troubles with the repair function, post a notice at the talk page. Wiimm will try to optimize this functionality.