MapConv Designed badly.

[enetheru]

It does like three or four separate jobs which IMHO should be three or four separate programs, and have a script/frontend do all the in-between works.

I know that some people would think that keeping it all together is smarter because its simpler for end users. but that's why you have front ends/scripts.

what I personally want to make feasible is creating maps out of tiles in the first place instead of just ridiculously large images

I've been running it on Linux, browsing through the source etc, trying to make sense of exactly what it does.

----
As far as I can tell so far:

It splits up the huge image into 1024x1024 bmp files then does something to them so they are 1024x1024 bmp.raw files

It calls the compression tools to make dds files in there somewhere(not sure if the raw files are dds)

It creates the minimap from the texture image.

It joins them into smf (spring map file), and smt (spring map tile)

then you have to use 7zip to join them all together into the sd7 archive(with any other resources and the smd (spring map description?))
----

What I want is creative control over each step(as much as permitted by the map spec), so its modular and people can write better intermediary utilities that perform certain jobs better, instead of having to replicate/replace MapConv with their version of an all in one tool.

I'm writing up some documentation on what exactly mapconv does. and also I want to create a really good specification of the map format. so if Behe or others can fill in some of the blanks from my knowledge that would be great !!

[Beherith]

http://springrts.com/phpbb/viewtopic.php?f=56&t=21458

Now with GUI - Thanks bruce!

[enetheru]

http://springrts.com/phpbb/viewtopic.php?f=56&t=21458

Now with GUI - Thanks bruce!

Thanks Behe, kind of wasn't my point though.

[enetheru]

Currently we have a tonne of stuff that goes into a program and out comes a complete map.

Instead what if we had a compiler that partially compiled a map, so we'd have a blank black map completely level that e 'inserted' or compiled portions into it? This could allow tweaks of existing maps or for huge maps built from lots of little textures, and would allow extensions added to the edges of maps without decompiling, resizing and recompiling.

I'm quoting this here because its relevant only in that splitting up the discreet functions that MapConv already does might inspire someone to develop portions of it like the above

[hoijui]

is this, what you (or AF) suggests there:
A kind of meta map-format, that is not used by spring directly, but to share all content required for a map in a common format (among map-makers, mainly), to make it easier to create different versions of a file, and apply small fixes and so on.
?

edit:
also, i saw that the last commit on MapConv on git is from October 2009:
http://github.com/spring/MapConv
while what you linked, Behe, is from December 2009.
.. should we merge something in?

[rein08]

What ia required to do a map?
I was just wondreing.
Thanks anyways.




Spartoo voucher

[enetheru]

What ia required to do a map?
I was just wondreing.
Thanks anyways.

There are some guides here http://springrts.com/wiki/Map_development