ufo2map

[geever]

Maybe, but it would be yet another awkward artificial trick to patch a problem. A REAL solution would be to code a client in C and compile it on each platform natively.

Maybe the REAL solution will be the in-game map downloader which is planned for MPs....

-geever

[Mattn]

which is already there for mp

[bayo]

How about including python binaries in the C::B package, though?

I dont think it is possible. It need a real installation. Merging both with be horrible.
Destructavator talk about Blender, but it is not the same, cause Blender use it as an extention.

[BTAxis]

Then maybe map-get should be implemented in something else. I don't think it's a good thing to require people to install a whole script language for just one script.

[Muton]

> utf-8 chars
now i got your point
@echo []
Its 0x07 ASCII Bell
Cause the speaker to beep once

> python
no problem to add it into C::B package
No installation needed, but do we add 2.6 and 3.1
Python26.7z
perl is included (but i'm sure some more Cpan modules are needed)


>I think I didn't get it either.
>So what are the requirements for mapget ? I know it
>- dowloads the newer compiled maps from some server
>- is needed for MP games so all clients use the very same maps
>- can be used to avoid compiling the maps yourself
>Anything else ?

Ok let me ...
Imagine mapget need to recompile some big maps, this can take hours
what to do with the non up2date bsp?
If someone is using mapget while the server recompile a map
the client will get a outdated map, but he dont know that (bugtracker->already fixed->i still have this problem->....)
or
The script run daily 0400 UTC
Someone is downloading a map at 0300 UTC but at 0100 UTC the map has changed
-> outdated map

So 2 of your 3 requiements are not meet
and they never will be
A new *.map need a recompile on server
this needs time
during that time the map is not up2date
The best thing in such a situation is not to download such outdated bsp's
and force a compile on the client

The only real way to be shure that all maps are current
is to store them in svn
A map-dev changes a *.map, compile it and upload both *.map and *.bsp
In that case you have instandly a current bsp
no one need to compile maps on his own
or have to wait h's to get it done
Everything else is just working arround the problem

[Mattn]

If someone is using mapget while the server recompile a map
the client will get a outdated map, but he dont know that (bugtracker->already fixed->i still have this problem->....)

i don't see a problem in the outdated map - why do you? rerunning the script the next day will fetch up-to-date version. i mean. if someone checks in a mapfix while you are compiling the maps.... you won't get this fix without svn up && make maps, too. i don't see any difference.

[bayo]

The only real way to be shure that all maps are current
is to store them in svn
A map-dev changes a *.map, compile it and upload both *.map and *.bsp
In that case you have instandly a current bsp
no one need to compile maps on his own
or have to wait h's to get it done
Everything else is just working arround the problem

Thinking people will spend 4h before commiting something is a dream. And i dont talk about ufo2map patches and the size (and the time) it need to commit/update in the case.

[Destructavator]

Thinking people will spend 4h before commiting something is a dream. And i dont talk about ufo2map patches and the size (and the time) it need to commit/update in the case.

I think he meant one map at a time, meaning if a specific map has corrections made, just that map would be re-compiled by the developer, and then both the source file and the compiled map would be then be uploaded in a commit to SVN.

A single map should not take anywhere near four hours.  The UFORadiant editor already has a command to compile the map for testing, doesn't it?

[Mattn]

bsps won't be commited to the svn - everything that must be compiled will only be commited with sources.