Slic3r messing up on extruder order

[RepRapMe]

Using Slic3r 1.2.9 when slicing files consisting of more than 10 extruders (Repetier-Firmware supports up to 16 virtual extruders for color mixing) via Repetier-Host then Slic3r sorts the toolpath as follows: 0, 1, 10, 12, 13, 14, 15, 2, 3, 4, 5, 6, 7, 8, 9 (and then in the next layer it's taking a shortcut to 9, 0, 1, 10, 11, 12, 13, 14, 15, 2, 3, 4, 5, 6, 7, 8)

The order should of course be 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15

Note this was not an issue with Slic3r 1.1.7

For comparison I have attached the gcode output from both version 1.1.7 and 1.2.9

Extruder order messup 1.1.7.gcode.txt
Extruder order messup 1.2.9.gcode.txt

[Virtox]

Will try to test it later, but looks like it's using the default lexical sort.
If you run the perl version, change line 542 of lib/Slic3r/Print/Gcode.pm
my @extruders = sort keys %by_extruder;
to
my @extruders = sort {$a <=> $b} keys %by_extruder;

And to skip the toolchange shortcut , comment out lines 543 - 551:
# if (@extruders > 1) {
# my $last_extruder_id = $self->_gcodegen->writer->extruder->id;
# if (exists $by_extruder{$last_extruder_id}) {
# @extruders = (
# $last_extruder_id,
# grep $_ != $last_extruder_id, @extruders,
# );
# }
# }

[lordofhyphens]

@RepRapMe Could you provide a config file and an STL/AMF so we can easily test this?

[alranel]

@RepRapMe, thank you, I fixed this. The shortcut is actually there by design and it's a feature: it will save a toolchange. Can you share your use case and why the shortcut is unwanted?