Version 2.3 update:
Added support for parsing feature placement lua files made by the feature placer (available by launching GUNDAM RTS 1.21 in sandbox mode)
Example line format:


Each feature will be placed at the specified position and rotation.
The command line parameter for this option is -k (example: -k featureplacer_export.txt). Note: the definition of rotation is still the same, as well as a rotation of -1 corresponding to random rotation.

-k featureplacement.lua

Mapconv advanced no scanlines version by Beherith. Also CUDA support added..

http://www.springfiles.com/show_file.php?id=2585

three new options added:
-z "string"
Optional parameter. Defines the texture compression method to be used by nvdxt. MUST contain -file at the END!

-r [number 0 to 255]
randomly rotate the first "number" features in featurelist (fs.txt by default).

Since first feature in fs.txt is number 255 red on feature bitmap.


IMPORTANT: ADDED FEATURES TO FS.TXT
You can specify a number between -32768 to 32767 to specify the rotation amount of that feature.

Multiple definitions allowed. 16384 is 90 deg counterclockwise rotatio, 8192 is 45 deg counterclockwise,

-16384 is 90 deg clockwise.
Example fs.txt:

btreeclo-3
btreeclo-3 0
btreeclo-3 8000
btreeclo-3 16000
btreeclo-3 24000
btreeclo-3 32000
btreeclo-3 -8000
btreeclo-3 -16000
btreeclo-3 -24000
btreeclo-3 -32000
btreeclo-3

-nmips 5 -file"

-q -z "string"
Optional, -q Enables CUDA for geforce 8 and higher gpus. Massive speed increase, less compression

options.

Example:
-q -z "-fast -bc1"
mapconv -c 0 -x 1200 -n -245 -o Grts_HarborA_01.smf -f f.bmp -t t.bmp -m metal.bmp -a HEIGHT.raw -q -z

"-fast -bc1"

mapconv -c 0 -x 1200 -n -245 -o Grts_HarborA_01.smf -f f.bmp -t t.bmp -m metal.bmp -a HEIGHT.raw -q


Examples:

Fastest compile, lowest quality:
MapConv -i -c 0 -x 250 -n 25 -o Zion_v1.smf -t t.bmp -a h.raw -m m.bmp -f f.bmp -z "nvdxt.exe -dxt1a

-nmips 4 -quick -file"

Medium speed, good quality: (CUDA version, requires nvidia 8 or higher series gfx card)
MapConv -i -c 0 -x 250 -n 25 -o Zion_v1.smf -t t.bmp -a h.raw -m m.bmp -f f.bmp -q

Slow, great quality:
MapConv -i -c 0 -x 250 -n 25 -o Zion_v1.smf -t t.bmp -a h.raw -m m.bmp -f f.bmp

Slower, best possible quality:
MapConv -i -c 0 -x 250 -n 25 -o Zion_v1.smf -t t.bmp -a h.raw -m m.bmp -f f.bmp -z "nvdxt.exe -dxt1a

-nmips 4 -Sinc -quality_highest -file"

MAY NOT SUPPORT LARGE MAPS OF 32*32 SIZE!!


If you need help, Im reachable at mysterme at gmail dot com

Thank you, but I was working on a 36x36 map!

Oh, look the Conspirators- oh sorry, the devs, moddevs and specialeffect guys once again bundled up to draw memory from those who only waist it anyway- hey they are just mappers, and nobody is playin that big maps anyway, so why should i work on something, that noobbody ever is gonna use? Lets face it, 16x 16 would be more decent, for that we could have more polys on the units, more detailed explosions and betta physicks. No need to invest it into those taking a map... well lets admit it if somebody of us would think it worth the effort, we would make a mapgenerator, getting rid of the bastards altogether...
*INVISIBLE COLLECTIVE NOD*

32x32.. for that limit, i award you with a shrinkhead

hell i am working on a 10x80 and all i get is this?
Nice work, but return to sender

Hrmph.
Shoulda just omitted that bit of info. Ungrateful bastidges.

Sorry, i know you worked hard, but, but i did that too, and my map doesent just stand there sayin that the work of your mapconv is from now on limited to the sparetime hours from six o clock evening to 12 o clock midnight. Lets call it the rage (or more accurate fear) of the heavily dependent- hrmph, okay, you force me into this, so (imagine me on my knees) allow it, for the megalunaticinsanityssizes-sake, pleeeaaaaazzzzee!!!!


Also: I started to get pissed of by this handpaint-a-typemap job i got myself into, hell on earth, i can see the columns approachin, tellin me (and you, that will make it easier) that our engines physic is buggy, because the hoovers climb that hill, and that one, which is similar high not... we need free virtual handkerchiefs with every spring... that is going to be my next feature request...

Also: Has there ever not been drama between artist and programmers? Logic meets walking emoticons for a epic battle?


Thx for your hard work, we really appreciate it, although it seldom shows

PS: I can haz "No-BuildTag for TypeMap?"

PS: I can haz "No-BuildTag for TypeMap?"[/quote]


Not for typemap, but you can Lua it in. There is a gadget in my map, TMA-0, it restricts giving commands outside of an area. Its an extremely simple gadget, and you can easily customize it to just disallow build commands. Look up the identifier for command types and your good to go.

behe is in the giving mood

hey feel free to lift my palm trees outta tumult for your tree thread. they have a neat reflective shimmer off the fronds.

Behe, you need to give some serious lovin to the process of explaining how this is to be used.

I just used one of your example lines and the map came out looking fairly crappy (using cuda).

Also, it isn't stated if using cuda or whatever else is better for quality, you're supplying a lot of options and giving us no idea what anything will do.

For example, the type of dxvt or whatever it is compression, first of all who cares, and second of all, wouldn't it be a lot nicer if next to each one you had (crappy) (better) (best) or at least something to indicate that this is a good or bad thing?

I have a neat idea. Supply 2 or 3 lines for us to copy and paste with quality ranging from worst to best so that an intimate knowledge of mapconv and/or dds isn't a requirement anymore.

Fastest compile, lowest quality:
MapConv -i -c 0 -x 250 -n 25 -o Zion_v1.smf -t t.bmp -a h.raw -m m.bmp -f f.bmp -z "nvdxt.exe -dxt1a -nmips 4 -quick -file"

Medium speed, good quality: (CUDA version, requires nvidia 8 or higher series gfx card)
MapConv -i -c 0 -x 250 -n 25 -o Zion_v1.smf -t t.bmp -a h.raw -m m.bmp -f f.bmp -q

Slow, great quality:
MapConv -i -c 0 -x 250 -n 25 -o Zion_v1.smf -t t.bmp -a h.raw -m m.bmp -f f.bmp

Slower, best possible quality: (Very highly recommended by me)
MapConv -i -c 0 -x 250 -n 25 -o Zion_v1.smf -t t.bmp -a h.raw -m m.bmp -f f.bmp -z "nvdxt.exe -dxt1a -nmips 4 -Sinc -quality_highest -file"

Thanks

I guess someone should write a little GUI frontend to pass all these options to it

And having volunteered, FLOZi decides to cry into his beer.

Very nice new version of mapconv even with the CUDA support :)

I have one question
(I guess this is related more to spring map "format"/requirements than this tool but this new version of mapconv make me to notice this):

So, if I have 8x8 spring map (4096 x 4096 texture), and I run the new mapconv I got the message
"WARNING: Metal map is being rescaled, may result in undesirable metal layout. Correct size is texture/16"

So, is the "optimal" metal map size xres/16 x yres/16 (where xres,yres from the original texture map)?

P.S. From complete map making tutorial (viewtopic.php?f=13&t=3941) Outdated? :
"Metal map Size: To get your Metal map size do this simple equation. Texture / 8 + 1 = Metal map dimentions. Therefore, if your map size is a 16 x 16 your Metal map will be 1025 x 1025."

Yes ismo, my version is correct, even I didnt know that that was the correct size until I poked around in the source of mapconv. Hence why I added the warning message. Your map will still work fine, its just a warning message.

Forb forgive me, Ill ninja edit your tutorial to reflect this.

There is a gui for mapconv but it does not have the new options included in it.
Any chance anyone will edit it to include the new commands?
Its on JobJol

I get a larger sized smt when using
-c 0.2 -nmips 4 -Sinc -quality_highest -file"
compared to using
-c 0 -nmips 4 -Sinc -quality_highest -file"

why is this? shouldn't it be the opposite way?

Not sure how that could happen. Is the filesize difference significant? Try running with -c -1 to disable compression completely.

The larger one was 68 mb, and the smaller 66.4 mb. I'll try with c -1 then.

At the end of the compile, it tells you how many tiles where used compared to total number of tiles. If its equal there was no compression.

Your posts in this thread say:

But on springfiles it says:

I tried the 1st one and it gave PARSE error. So maybe you should correct that. I'm still having problems getting compression with any setting using your mapconv..

UPDATE!:

With -c -1 it writes 102400/102400.

With -c 0.5 it writes 100860/102400. Smt size remains nearly the same.

Here's the arguments I used:

MapConv -i -c 0.5 -x 450 -n -77 -o Battleground.smf -t texture.jpg -a height.bmp -m metal.bmp -f feature.bmp -y type.bmp -z "nvdxt.exe -dxt1a -nmips 4 -Sinc -file"

What do I need to change to get some decent compression?