I tried to change the player skins with mapscripts using rempashader commands (so on winter maps like Fueldump Axis have winter clothes). Though it doesn’t seem to work, either because I made something wrong or you can’t remap shaders for player models this way.
Here is what I’ve done (for Axis engie on Fueldump):
http://forum.splatterladder.com/index.php?act=attach&type=post&id=2071
Maybe someone can have a look at it?
The line
remapshader "models/players/temperate/axis/engineer/body_engineer.jpg" "models/players/winter/axis/engineer/engineer_body"
in the map script actually does change the skin, but the texture is messed up.
What have I to do to make the pk3 work?
Tested it in etmain and still see the standard-skin for the Axis engineer.
You need to run it with a mod which supports mapscripts. Place the pk3 into the mod folder and run Fueldump with the mapscript from the zip file.
But like I said for some reason it doesn’t work as expected.
No chance for me to get it to work. 
Tried to put the changed mapscript in a pk3, too, but still no success.
I did something like that for the map resurrection
on peyote.googlepages.com, in the skinpack …
edit: the limit of remapshaders is pretty low, is it possible to have many md3 use same shader as source?
So that all textures are in on big texture for the player skins? Is it possible todo that somehow easily?
I guess it needs all affected md3’s to be changed, but well … maybe its worth the trouble… at the end it would only need one remapshader cmd for each team…
Afaik W:ET has an overall limit of 128 remapshaders.
I don’t know if there is a limit for the combined length of all remapshader commands (for sending it over the net), but you could partly avoid this by using short shader q-paths.
The amount is the limit of remapshader commands flushed at a time. So you have basicly infinete if you flush them in separate, like a little wait between flushes.
It works like charme if you change the textures of the playerskins with the remapshader. Thanks to ailmanki for showing how it’s possible!
A few days ago I began to work on a pack with specific playerskins (grey, black, desert, winter for the axis and green, beige, desert for the allieds, including fixes and fixed scripts), but my computer cheased to exist. Harddrive is still intact, so nothing ist lost. Good reason to buy a new one. 
Figured out that some maps like Fueldump and Goldrush won’t start if you use to much remapshaders, but it was always possible for me to change the body skins.
To bad I can only continue the work on it until a new pc is delivered, wanted to release a set of good playerskins wich fit to the models along with examples to make it easier for server admins to build it in maps.
Sage, a example would be nice of how to build in the wait for the remapshaders.
I guess he means something like:
game_manager
{
spawn
{
// First remapshader batch
remapshader "old shader q-path #1" "new shader q-path #1"
remapshader "old shader q-path #2" "new shader q-path #2"
remapshader "old shader q-path #3" "new shader q-path #3"
.
.
.
remapshaderflush
wait xxx // Long enough wait command to give server chance to send the remapshader-list
// and allow clients to receive and apply the list
// x-th remapshader batch
remapshader "old shader q-path #x1" "new shader q-path #x1"
remapshader "old shader q-path #x2" "new shader q-path #x2"
remapshader "old shader q-path #x3" "new shader q-path #x3"
.
.
.
remapshaderflush
// continue will default spawn trigger stuff
.
.
.
}
.
.
.
}
To decrease the overall wait caused by wait-commands, you could change the parameter of subsequent wait-commands in the trigger (resp. omit them completely).
As an alternative you could also dispatch the remapshader-list to a newly created entity, which calls itself until all remapshader commands are sent (though this is just an idea, so don’t blame me for bugs or if it doesn’t work as expected ;)):
game_manager
{
spawn
{
create
{
scriptname "remapshader_scheduler"
targetname "remapshader_scheduler" // necessary?
origin "0 0 0" // necessary?
classname "the class name" // choose some uncomplicated class name w/o side effects
mins "0 0 0" // necessary?
maxs "8 8 8" // necessary?
}
.
.
.
}
.
.
.
}
remapshader_scheduler
{
spawn
{
wait 100 // necessary?
trigger run_batch_1
}
trigger run_batch_1
{
// First remapshader batch
remapshader "old shader q-path #1" "new shader q-path #1"
remapshader "old shader q-path #2" "new shader q-path #2"
remapshader "old shader q-path #3" "new shader q-path #3"
.
.
.
remapshaderflush
wait xxx // Long enough wait command to give server chance to send the remapshader-list
// and allow clients to receive and apply the list
trigger run_batch_2
}
.
.
.
trigger run_batch_x
{
// Last remapshader batch
remapshader "old shader q-path #x1" "new shader q-path #x1"
remapshader "old shader q-path #x2" "new shader q-path #x2"
remapshader "old shader q-path #x3" "new shader q-path #x3"
.
.
.
remapshaderflush
// additional wait required here? (to prevent entity deletion until remapshader-list is sent?)
remove
}
}
This way you could use a long enough wait times after the remapshaderflush-commands, w/o delaying the execution of the trigger game_manager->spawn too much.
Though this approach would require support for ETPro map scripting.
I guess he means something like:
game_manager
{
spawn
{
// First remapshader batch
remapshader "old shader q-path #1" "new shader q-path #1"
remapshader "old shader q-path #2" "new shader q-path #2"
remapshader "old shader q-path #3" "new shader q-path #3"
.
.
.
remapshaderflush
wait 500 // Long enough wait command to give server chance to send the remapshader-list and the client to receive and apply the list
// x-th remapshader batch
remapshader "old shader q-path #x1" "new shader q-path #x1"
remapshader "old shader q-path #x2" "new shader q-path #x2"
remapshader "old shader q-path #x3" "new shader q-path #x3"
.
.
.
wait 500
// continue will default spawn trigger stuff
To decrease the overall wait caused by wait-commands, you could change the parameter of subsequent wait-commands in the trigger (resp. omit them completely).
now I understand … this will be beautifull!
I always thought its limited… yay! So they do add to the so called “max gamechars”, when it is sent?
Now the only thing we should find out is the minimal waiting time, I wonder if it as affected by playercount… Time for experimenting… >3 ET
Besides, for customs skins having to wait a second at map start… isnt big problem… I see more the problem of a player seeing how the skins do change… looks like buggy maybe.
Funny the scheduler would allow for rainbow colors… lol , changing the uniforms color every few seconds… :D… very funny… maybe an Idea for christmas … hmmmm -> easier with a shader only, !slap myself…
What Ragnar said is what I was meaning, thx for the example. However I still see the need for 128 remapshaders at a time. It’s heck of an amount, even for a skin pack.
Usually this all will happen during warmup (the mapscript will start twice - once at the beginning of warmup and once at the beginning of the round). When the script starts for the second time all skins should allready have changed, so during play no skin change occur.
But you can also add some wm_announce commands like
wm_anounce "^3The supreme command ordered winter clothes!"
, so players know whats going on.
I am getting crazy… seems you had been right Firefly 16 …
I worked now long on that permap skinpack… Crazy stuff… Lots of headache…
********************
ERROR: G_FindConfigstringIndex: overflow: [ jr ] [ 576 ] [ 32 (cur 32) ] [ qtrue ]
********************
----- Server Shutdown -----
==== ShutdownGame ====
that is what I get with :
remapshader "models/weapons2/arms/arm_allied" "a" // 1
remapshader "models/weapons2/arms/arm_axis" "b" // 2
remapshader "models/weapons2/knife/arm2" "c" // 3
remapshader "models/weapons2/mp40/winter/hand16" "d" // 4
remapshader "e" "f" // 6
remapshader "g" "h" // 7
remapshader "v" "q" // 8
remapshader "w" "m" // 9
remapshader "y" "o" //
remapshader "z" "p" // 9
remapshader "aa" "i" // 10
remapshader "ac" "r" // 11
remapshader "af" "k" // 12
remapshader "x" "n" // 9
remapshader "ab" "j" // 10
remapshader "ad" "s" // 11
remapshader "ag" "l" // 12
remapshaderflush
I really tried to keep em short… they shaders had been first more descriptive … but it did throw that error… so I thought lets shorten them more… but nei
There are 17 remapshader with 16 it works… So maybe we can remap the same shader 128 times, that i did not check. But remapping different shaders does not work.
Well this is pretty sad… as Allies had been almost finished… the last “ag” “I” is a new helmet…
So I have come to conclusion, only replace skins from team per map. Allies fit desert theme, Axis almost everything except snow. So I guess creating a skinpack where all classes share the same clothes would be make it possible… one helmet for all… and so on…
(5 helmets + 5 bodys + 5backpacks = 15… well no room to replace the hand, and have a naked body…
soo it needs allot of saving, beside that some maps also use remapshader.
Your idea Ragnar_40k did not work, making a logic which does kinda dispatch the remapshader commands did fail, I guess its because they are all recorded. So that a player which joins later has the same shaders as one which is allready in (G_FindConfigstringIndex).
So basically one can call maybe 128 remapshader , but not replace as many.
I still hope I am to tired and have failed -> overlooked something and it should work… lol
But I guess not.
Has anybody interest to help making that skinpack? Would need a light skinpack, which uses max 10 - 12 textures, so that they can be replaced by the mapscript.
Did you checked the result if you replace body textures with “remapshaderflush” command?
I used as example this:
remapshader “models/players/temperate/allied/soldier/helmet.tga” “models/players/temperate/axis/soldier/helmet.tga”
remapshader “models/players/temperate/allied/soldier/body.tga” “models/players/temperate/allied/cvops/body.tga”
remapshaderflush
I checked on Darji2 becuse there is a mirror (but can be recording demo and use 3rd view for the replay) and :eek:
PS. Ah, just saw, Ragnar_40k wrote same…
hehe there is a good map for this… contains a big mirror…
http://www.wolfmap.de/details.php?file_id=226
I have too but I got used to Darji
also i tried replacing the mdm and md3 files, using names for the textures which are not shader-edbut the result are alwas crap. It was a fast test, so maybe possible solution, but…