[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead [phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead [phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead [phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead [phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead [phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead [phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead [phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead [phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead [phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead [phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead [phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead [phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead [phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead [phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead [phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead [phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead [phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead [phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead [phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead [phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead [phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead [phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead [phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead [phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead [phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead [phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 112: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead [phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 112: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead [phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 112: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead [phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 112: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead [phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 112: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead [phpBB Debug] PHP Warning: in file [ROOT]/includes/functions.php on line 4783: Cannot modify header information - headers already sent by (output started at [ROOT]/includes/functions.php:3897) [phpBB Debug] PHP Warning: in file [ROOT]/includes/functions.php on line 4785: Cannot modify header information - headers already sent by (output started at [ROOT]/includes/functions.php:3897) [phpBB Debug] PHP Warning: in file [ROOT]/includes/functions.php on line 4786: Cannot modify header information - headers already sent by (output started at [ROOT]/includes/functions.php:3897) [phpBB Debug] PHP Warning: in file [ROOT]/includes/functions.php on line 4787: Cannot modify header information - headers already sent by (output started at [ROOT]/includes/functions.php:3897) TribalOutpost.com Forums • View topic - Total content repository
Two of the most frustrating things when I was mapping (or getting maps) in T2 were
1) Having to search for content - bases, textures, etc. which were spread over different packs throughout the Tribes community
and
2) Ending up with multiple copies of the same content, because it all got packaged up by individual maps in an arbitrary fashion.
Additionally, when I spent a lot of time creating a script or a base that I ended up not using, it would have been nice for other mappers/scripters who were clamoring after that content to be able to head to one central place to get it.
I would suggest that you put some thought into making a repository on the new site for allowing people to upload content, and automatically place it in a standardised format for others to search through and download from. Where content is repeated, rather than storing multiple copies on your site, just maintain links to the existing material.
For example, perhaps the standard directory tree for content were as follows:
Content\
- Maps\
- Textures\
- StaticMeshes\
- Animations\
- Sounds\
- Etc\
When a map is submitted, users specify all the files they are "adding" to the repository for that map (which they will need to do anyways in some format, although it may just be easier to parse the files out of a single zip file). Then on the site, all the content is stored in the appropriate folders (and in some cases will not need to be replicated - saving some space) so it is all available in a standardized format and in one single place. When users search for a map on the site, they will not be looking for a .TVm file (which wouldn't be able to contain all the content anyways) but rather a simple entry that you generate which has the authors submission information (including the references to the associated files for that map). When downloading, you just need to send the referenced files.
In other words, unzip stuff to the repository on submission, maintain the referencing information as a part of the author's submission info, and zip it back up (if that would be preferred to sending out the files individually) for download.
I believe something along these lines would make it easy both for users to download maps, and for developers to keep up to date with all the available content that the community has developed.
since this is a T:V forum, im going to talk in terms of T:V.
we have enough experience in Tribes2 with people just taking other people's work and not giving credit. now, what makes that extra pathetic is that "CS" mapping in T2 already means you are kinda marginalized with the way files are organized.
in Unreal/T:V land, mappers SHOULD make their own custum stuff as integrated within their maps... UNLESS they make a conscious effort to build up some external packages of mesh, textures, sounds, etc... stuff designed to be used beyond just the one map.
how to organize files on this site is an open question, and we're far away from really being able to even make suggestions since T:V itself isnt out yet. but let me map this out as one way of doing this, IF it were just like ut2k3...
1. Mappers upload a zip file
2. Inside the zip: Map; 3 screenshots; any extra texture, sound, mesh, or other "packages"
IF you upload a texture package called Organics.utx and there is already one in the database, you will be tarred and feathered.
See, here's the deal. You can put textures INSIDE the map itself as a package, instead of as an external package/file. You can easily grab stuff from somebody else's map.
If they make an independent set of packages, perhaps THAT is what could be set aside by the site. In that case, this concept makes some sense. I just wouldnt want to see one big friggin mass of packages without some proper naming rules!!!!
Personalyl, i do not think the community has a default right to just willy nilly grab stuff from others with no respect or credit given, and thus i dont think this site (i.e. bytor) should spend one minute of energy workig out a system for doign what's already available for a dedicated mapper.
IF YOU REALLY NEED some "repository" for finding/using stuff you didnt even make... you are one lazy MOFO and shouldnt be mapping. (certainly nobody here is THAT lazy)
On the other hand, obviously "packs" of custom stuff are really useful. That takes effect and planning. It's worth doing, but that's actually a separate issue.
Once we see how files and assets are managed in T:V, we can better figure this all out and make suggestions.
Again, personally, im not going to go out of my way to make independent "shared" packages/files for stuff i make. All that does is create potential problems for running MY map(s). Somebody overwrites or changes that external file, boom. My map is toast. Now, if there were several maps which were designed together using the same... trees, textures, etc, then it makes sense to build common packages they all use. IF i work up front in that manner, ill want to have external files on top of the maps. But only in that situation... that's just me.
If something like this is to be done, i'd suggest really, really strict file naming rules, if not managed by script.
If you put up a map and a texture package with it in a zip, that package oughta have a name based around either the map or the author, like MyCoolMap_Textures.utx or TseTse_Textures1.utx
But again... here's the question.
If you want to download TseTse_Textures1.uxt then you oughta download the MAP done with it. I'd grab a baseball bat and go at somebody who didnt have the respect to actually check out the map before just pillaging the assets designed for the map.
On the other hand, this kind of system would allow folks to upload textures and mesh by themselves, potentially.
Honestly, if this community were choke full of texture artists and modelers, that would be really cool. But we have mostly people who havent even opened worldcraft, let around unrealed or max...
i give thumbs up to a simple "index" of assets, just not a full database where you download stuff and such. IF the community ends up with tons of high quality texture packs and such... then maybe that would be cool. a big IF
I agree with you TseTse, though I am one of those who "havent even opened worldcraft" (Well I did about a year or so ago when I though I could make a Counter-Strike map...) but you can't equate 3DS Max into this situation can you? I mean it's at best a $450 program and at worst $5000. Unless you want us to pirate it.
And more for my credit I had the 30 day trial of max. Made a cube...
there will be a Gmax pack for ut2k3, which i HOPE works for t:v. Gmax is basically a free version of Max designed for specific game file formats.
and of course, there's always Maya (Personal Learning Edition). it's comparable to Max, and the PLE edition is free with some nerfed settings. it's on the ut2k3 cd3.
grab that, then go to
there's 4 hours of video training for using maya to make characters for unreal... plus many more hours on just general maya use.
If I were to create a content database for the site, people would post material to it with the understanding that they are offering up their goods for anyone to use in any manner they desire.
There is no way to programmatically enforce copyrights or even requests for credit when it comes to using raw materials in a map. Therefore, anyone posting material must understand that they are giving up all control of how the material is used and whether or not they will receive any recognition for it's creation.
It would be no different than the myriad texture, font, icon, etc. sites that permeate the web. You are effectively putting your work into the public domain. It's either that, or you set up a credit card charging system (like some sites do for fonts, for example.) Obviously, that won't happen here, so we're left with the public domain concept. I don't see any effective, enforceable middle ground.
Perhaps there will be big bold letters on the submission form that say "Any material you submit to this database enters the public domain and you forfeit all copy rights and claims of ownership blah blah."
Of course, setting up the content database in this manner does not solve the issue of unique file names, but it doesn't create the issue either. I'm open to suggestions on approaching that problem.
Whenever a VL2 is posted to tribes2maps.com, my script extracts all the filenames from the zip and stores them in a master index. This index is used in conjunction with the autodownloader script to locate a VL2. Perhaps that same concept could be used to "validate" the filenames in submitted raw content packs to make sure the names are all unique. Of course, that creates a problem where people will rename a texture just to get their package into the database, even though the texture is exactly the same as the one already in the database. Is that a bad thing? I dunno.
One way to combat that issue is to save checksums on each and every file, so that my script can verify that a submitted file with the same name as a file already in the database is in fact the same file. That can chew up a lot of CPU though, calculating all those checksums.
Anyway, thinking out loud here. Comments?
-Bytor
"If at first you don't succeed, die and die again."