- Status Closed
- Percent Complete
- Task Type Bug Report
- Category 3D Art → Models and Maps
-
Assigned To
Mike Gist - Operating System
- Severity Critical
- Priority
- Reported Version
- Due in Version Undecided
-
Due Date
Undecided
-
Votes
1
- peeg (23.02.2009)
- Private
Opened by Lanarel - 23.02.2009
Last edited by Mike Gist - 24.04.2009
FS#2784 - Current way of using art and data to get a working set not workable
After spending another week without a working client and getting a description "replace this file from svn art in this zip file from install art" from another tester who spent valuable time finding that out, I demand a better procedure, and will ignore all procedures by assigning this as a critical bug in one go.
Currently art and data come from 5 places:
- art and data from the install (possibly after running the updater on the install using the standard repro)
- art from the svn art branch
- data from svn trunk
- art and data obtained by running the updater on trunk using another url
- files given by people "use this, it will fix things"
Try figuring out when things do not work after doing things in the wrong order. An example, currently trunk does not work unless you take a few files from default.zip in the art branch and put them in the default.zip from installed art. If you take one or the other, things do not work. And I am not even sure this will solve the fact that none of the maps load at all.
With many art related bugs to test, this will just not do. We need a clear procedure that is also used by the devs that should at most be as complicated as this:
1. copy all art from install
2. copy data from install, but do svn revert on data/gui
3. ignore the art branch
4. update with normal url to get a working set (unless CS requires completely new art, then art from art branch at least should work).
5. update with not public url to get a working set for testing trunk with newest versions of at least released art.
Or any other procedure that uses a clear order of copying and does not change everytime a file changes.
24.04.2009 14:36
Reason for closing:
Additional comments about closing:
Closing as steps are being taken to
improve this.