UFO:Alien Invasion
Development => Coding => Topic started by: Muton on April 24, 2010, 02:19:26 pm
-
Tye BIG problem with ufo2map and maps as a whole is
to keep them up2date
recompile them all, all the time again and again is VERY time consuming *oh really?*
and frustrating
map-get.py is NO alternative (yet)
currently 110 maps are are not up2date
just a view of them
bunker.bsp, city_train.bsp, corrupter_crash.bsp, england.bsp, estate.bsp, farm.bsp, ferry.bsp, fighter_crash.bsp, fueldump.bsp, harbour.bsp, lake_ice.bsp, lake_ice_big.bsp, office.bsp, oriental.bsp, oriental_mosque.bsp, resort.bsp, rivertown.bsp, subway.bsp, tower.bsp, village.bsp, wilderness.bsp
At the moment there is no real easy and reliable way to determine if all maps are up2date or not
You can use a hash for a map file instead of trusting -onlynewer switch of ufoai
but there is no such way for ufo2map itself
Its possible to hash ufo2map the same way as maps to reliable find a modification
But if a dev just corrects a spelling
you end up thinking ufo2map has changed and starting to recompile all maps.
To determine what a dev has changed and how this effects map compiling is nearly impossible
How to fix it?!
We already have a version number
we need a revision number too
In that case a dev modifying the code in a way that a recompile is necessary
he/she/it just increment the revision number
using the new -V --version switch will return the Version and revision number
version:1.2.5 revision:1
This way we can precisely determine if it really necessary to recompile all maps or not
I've done this and adding more -nice options for NT5++
-
Cool to see you working on this. 8)
I thought till now, that I can trust map.get.py & that the maps on the server are compiled there each midnight ?!
Thanks for the info that this is not the case. Good to know before posting outdated bug-reports :-[ :-\...
-
the fist step
http://sourceforge.net/apps/trac/ufoai/changeset/29704
-
it would be nice if you could remove utf-8 chars from batch files and if you could write them human readable ;)
also why not fixing map-get.py to help everyone? writing a batch file that only windows users can use is not a nice option to get rid of the problem.
-
You forget that Windows users can't use map-get.py in the first place, unless they install Python first.
-
also why not fixing map-get.py to help everyone?
Isnt it a server side problem? The server dont have the last maps, then map-get do not download it.
-
> utf-8 chars
uups win 7 notepad do utf-8?
> human readable
dont want to add another file
so thats the cost of "embedding"
> why not fixing map-get.py
thats the third step
Far to complex to fix and test it on one day
> Isnt it a server side problem
The whole idea is a problem ;)
Its useless if the files on the server are not always up2date
than you need a logic to handle file changes during recompile
The biggest map took 3,5h to compile
And what happen if someone is downloading a map and the script do apply the new one in the same moment?
-
> Isnt it a server side problem
The whole idea is a problem ;)
The whole idea can't be the problem, the players need to have exactly the same maps (checksums) for multiplayer...
-geever
-
> Isnt it a server side problem
The whole idea is a problem ;)
Its useless if the files on the server are not always up2date
than you need a logic to handle file changes during recompile
The biggest map took 3,5h to compile
And what happen if someone is downloading a map and the script do apply the new one in the same moment?
i'm not sure whether you got the idea behind this ;)
-
You forget that Windows users can't use map-get.py in the first place, unless they install Python first.
What about a portable python package? The people making the new and upcoming version of Blender have been packaging a portable package of python so that when the whole thing is done modelers won't need to download and install python first.
If this would work for UFO:AI scripts, then we could just have the python scripts and not need any batch files or other little odds and ends that only work on one platform. That and the .sh scripts could also be done away with and replaced, because they can be a pain for Windows users to figure out how to run (especially for non-programmers).
I admit I'm not a veteran programmer and I don't know as much about these things as some of the others here, but I've seen some of these things that have been mentioned bundled in portable packages before, then customized for various uses, set up to work on more than one operating system.
-
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, 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.
Perhaps that should be done then? Ufo2Map.exe is already like that, compiled for each platform, isn't it? Perhaps that utility could be expanded to take over the functions that the scripts currently provide?
I just wish I had more experience with C and C++, If I did I would volunteer to do it myself.
-
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.
Too much work for nothing. Things inside /contrib, compiling maps is not a "player" skill. Then installing Python is not an horrrible gap. Plus, I use Linux an i also must install Python to use map-get.
I really dont see the point. If you can't download a package, if u can't download maps (map-get), u must compile urself maps (ufo2map).
-
How about including python binaries in the C::B package, though? Keep all peripheral downloads in one place.
-
i'm not sure whether you got the idea behind this ;)
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 ?
-
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
-
which is already there for mp ;)
-
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.
-
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.
-
> 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 (http://www.meduniwien.ac.at/user/michael.zellhofer/ufoai/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
-
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.
-
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.
-
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?
-
bsps won't be commited to the svn - everything that must be compiled will only be commited with sources.