1) delete all models with more than 500 kb (becasuse such huge models are useless, at least in multiplayer) and as well limit its submision.
The problem with that it quality is not taken into consideration. We take quality over file size any day. We will never potentially delete a high quality piece of work simply based on file size.
2) check older version of maps and delete old versions of maps. There is dozens of maps submitet more-than-once because there is different versions - and is supposed that last version had to be played.
Its already that way now. If there are any obsolete version maps up, its because they slipped through my fingers or have other factors involved (such as multiple authors and not knowing which one is the original).
3) there was many broken links, but are you sure that files doesnt exist? Perhaps there is much space consumed by unlinked files.
Broken link pages are not taking up any space. I am intentionally leaving some broken link resources up in hopes of repairing them, because some of are best resources are broken at the moment.
4) make more and harder rules for submiting WoW models - they are huge and numerous.
Full optimization is already a requirement. Maybe it is not being enforced. File size and poly count should be heavily reduced as it is. Character models are the only tricky part because those are going to be large in file size anyway due to sheer complexity.
5) prohiby spells with custom models and stuff where these imports are not neccesary for functionality of spell (bars, or whatewer, not planes in fligth system for example)
Agreed.
There's a thing I don't get tho, half of the skin\map section has been recently lost, so how could there be space problems just a month later?
That was our external archive (our archive is in 2 pieces- wc3sear.ch internal and the over-flow archive hosting on another server composed of mostly maps and skins). It was once hosted on wc3campaigns, then when they shut down the first time it was moved to wc3anvil. Wc3anvil has since lost that archive, creating all the broken link resources I had to remove, although as I mentioned above, some are staying up as I plan on repairing and rehosting them.
Hmm a complete purge of the entire map section. . . That might just work since someone out there must have a copy of every good map from this sites map list.
But it is a bit extreeme. . . Lets just wait and see if darky manages to hagle extra server space from his provider. We can pretty much do nothing else but wait and hope. . .
A purge would do nothng. Uploading has been halted by the provider. Even if we had no files, we would not be able to upload anything. Get it?
If we get the stop lifted, then we may consider what to do as far as space conservation, but until then I will hope that darky succeeds in obtaining more space. Although I doubt doing anything for this site is on the top of his priority list, so I dont know what to expect. If we get no new space and dont get this stop lifted, then I will keep all the current files up just so there is something for people to download. -VGsatomi
PurplePootThe BLPaletter and MDX Squisher do not compress the file you target normally ( assuming these are the programs you are talking about ) but instead, change them so the MPQs can compress them more efficiently.
They'd still help since this site zips all resource and zip compression will have the same effect to paletted BLPs and squished models as the MPQ compression.
Masterful_Tauren It seems that there is no way through this dilema.We should purge all outdated files and start again,fresh.
Bad idea. Many old maps (as well as resources) are really good and then it shall be preserved to future. You can see most maps, even old, have permanently increasing download counter.
Note; 1B = byte = 1 byte = 8 bits 1kb = kilobit = 1000 bits 1Kb = Kilobit = 1024 bits 1KB = KiloByte = 1024 bytes = 1024 * 8 bits = 8.192 bits I appologize for the size of this post. I don't post too often, yet when I do, it gets messy . End_of_note;
A purge including only file deletion is out of the question - we all know this. No one would like his file to get deleted, just like that, on subjective reasons.
Tight rules must be implemented, otherwise this issue will occur again. Sooner or later, it will appear again.
A more complex yet community-dependent idea would be to issue 2 ratings to a map: 1 for admins and 1 for users. This way, all moderators of "Maps" could rate the map. In the end, the server computes an average - that's the Admin Rating. Users should also rate the file after they have downloaded it. I would suggest enforcing a download restriction for files in the same section: if one downloaded a map, he/she shouldn't be able to download one more untill he/she rates that map. It would be rather frustrating, tough effective (as anyone would soon be forced to begin rating files they download if they want to download another). So, perhaps you can change the site coding, implementing a new user section in the User Control Panel/User Console called "Ratings". There should be created entries to all downloaded files. If the user does not rate let's say, 50 files per Site section, he should be denied downloading more files from the same section untill he rates at least 50% from his downloads - or 100%. When he/she reaches the 50 files threshold, the restriction is activated again and so on, untill users learn to always rate files. With user ratings, the site could then compute a new average - the User Rating.
Based on these 2 ratings the site would finally compute a single rating - the File Rating - let's say about 75% Admin Rating + 25% User Rating - or 50% each, you decide.
Using a certain rating minimal value, after 1 or 2 or 6 months the site would compute a threshold. Take the file with most downloads ever in each section(considering it the best file/most popular file in it's section). Take the file currently checked in the same section. Compute an average downloads-per-day value for each file. Compute what percentage does the currently checked file's download average represent from the download average of the most popular file. With this value and the File Rating, the site could decide either to issue a warning to the author of that file, or to delete it. Or, to highlight it to a moderator. Whatever the Admins decide to program the site to do.
The age of a file shouldn't be a variable. Computing that downloads/day average uses the age of that file, yet it doesn't use it directly, it's rather computing the effectiveness that file has in download terms. W3 Viewer was created, let's see, back in 2003? 2004? So it's more than 2 year-old. Should it be deleted just based on that? No.
Yeah, this would create a whole lot of text entries (worst case, every user has been rating every file on WC3S, so that would lead to TotalNrOfFilesOnWC3S * TotalNrOfUsers entries). I just wrote a 268.435.456 bytes (256 MB) text file with every character in ASCII from #0 to #255. Compressed with Zip at Best (using WiRAR), it got down to 1.041.330 bytes (0,9930896759033203125 MB) - that would be 0,3879256546497344970703125 %. Not that big anymore, huh?
1) Maps. I do not know what to say about the maps section. It is not my field of expertise in W3, so I leave this open for you. Main idea would be to have a size limit corresponding to it's dimensions (map dimensions as W3 uses it, not as filesize). Then, maps should receive a rating, based on a composite metric: complexity & playability & overall quality & detail level & blabla - as I said, this is not my domain, so I do not know what fields should be present here.
2) Skins & Icons. Detail level is a REQUIRED field for these sections. The skins/icons would better be obtained by merge/scratch work. Recolors are out, as copy-paste are too. For Icons, a BMP with 32bpp is max 64(width) x 64(height) x4(32bpp = 8 Bpp) = 16.384 bytes (16 KB) large. A full pack would be 4 times that, so 64 KB per icon, provided it comes with all BTN, DISBTN, PASBTN, DISPASBTN BLPs. For skins, a BMP with 32bpp is max 256(width) x 256(height) x4 = 262.144 bytes (256 KB) large. These were BMP uncompressed sizes. Now, BLP compression kicks in - reducing as much as it can. Zip comes next.
I'd make a suggestion here. Wouldn't it be better if WC3S would only host the original image? For example, just the BTN image in BMP 16/24bit format or the BLP, compressed as ZIP. The download link should have below it a download link to a BMPtoBLPconverter/Warcraft3 Viewer or any other program capable of converting a BMP to a BLP with an user-friendly interface (we all were sometimes wondering what the Hell should we do with that ZIP file ) with minial input requirement and composing the required BLP files only from the source image (from only the BTN BMP file to all the 4 BLP files, BTN, DISBTN, PASBTN and DISPASBTN, also adding the Aplha mask).
This would get the pack size to a theoretical 25% (1 out of 4 images). From my MedalionOfWisdom (BTN image, 64x64 24bpp BMP file): BMP 32bpp: 16.440 bytes -> 12.150 bytes of ZIP archive BMP 24bpp: 12.344 bytes -> 10.883 bytes of ZIP archive BMP 16bpp: 8.248 bytes -> 6.057 bytes of ZIP archive BLP : 10.498 bytes -> 8.093 bytes of ZIP archive
The BLP file was composed from the BMP 24bpp and was added an Alpha Mask by Warcraft3 Viewer.
After all, the DIS, PAS and DISPAS are not distinct images compared with BTN. So, those files are just ballast. Implementing a software-independent program that could offer centralized image conversion and processing (allowing the user to obtain any of the BTN, DISBTN, PASBTN or DISPASBTN BLP files only from the BTN source image - either TGA, BMP or JPG) would lift the burden of space waste from the server.
3) Models & Spells. I am no modeller, so I am not the one to suggest rules here, but a general Quality versus Size rule is necessary. You can't delete a file only based on it's age or size. These factors are generic. A rule based on quality it's definetly the best option. Poly count is critical. I am not familiar with what does W3 do with skins, tough... Are they temporarily extracted to a temp folder? If so, a large number of textures per model would lead to free-space fragmentation. Ugly. Users should anyway be encouraged to use a number as low as possible of texture files per model. No other ideas here...
4) AI & JASS. The AI & JASS files are, if I recall, text files. So, ZIP should be enough for them. Or, RAR with Solid Archive set to true .
5) Art. This is fan-related. I don't know if any rules are/can be rephrased here... It's a question of personal taste, don't you think? I'd suggest encouraging users to host their files to sites like ImageShack.us. After all, these are personal files, so IS.us shouldn't have anything to say about it. A thumbnail and an URL would be enough in WC3S.
6) Tools. Hm... This is the category where I tried to upload yet encountered a refusal, so I may not be the person to be considered 100% objective. Tell you what? I'll try to be 75% objective. I guess is the best I can do.
As tools require programming skills, I don't think they are a serious problem for WC3S. First of all, because they are not going to be like thousands of them, as Icons/Models are. On the other hand, they can be very large.
Some rules I'd suggest here: no tools platform-dependent should be allowed. If you do not accept icons for models that do not exist for the time being, why should you allow such tools? I downloaded some while ago the W3 Damage Calculator (Yeeeah! only around 500KB! a joy for my crappy dialup connection, that offers me some 1,5/2 KB per second, 3 KB/sec in the good times!) and, when it was all over and I tried to run it, I have been announced that I need some .NET framework installed to run the damn thing!
Please Note: I express no opinion regarding W3DC's quality: I was unable to run it. I only refer to ability to run a program.
So, Please do not accept tools that can't be run independently, as standalone EXE file. Even if they do need some DLLs or other files, they must be WITHIN the download archive, not on third-party website. On the other hand, there shouldn't be like 50 tools for the same function. If you could, only accept or encourage at least those tools having implemented the most functions! Tools should be allowed to be complex as long as they are compact. Egonomic interfaces should be encouraged by pertinent feedback such as comments and such, while the number of files per program should be kept minimum. Tools should have complete documentation along the program files. Yes, it's good to help/be helped by forum members, but always seeing the same thread title/question in comments as "Why can't I run the program" gets both tiresome and increases the number of text entries in forums, making it more of a jungle. Basic usage tutorials within download ZIP archives should at least be encouraged if not required to exist.
7) Forums. Implement an archive module for posts older than 1 year, for posts that have not been viewed for a long time or for posts that have not been replyed in a long time. After 1,5 / 2 years, either pack them as ZIP/RAR/CAB/ACE/UHA or delete them. Although, keeping a record would be interesting.
Donations should and perhaps ought to be made more often, provided you're in a country with PayPal support...
If the server is Win-based, perhaps defragmenting it from time to time would lead to improved speeds and lower free space fragmentation?
Over all, composite metrics would be the best option in defining the "quality" aspect of any uploadable resource.
Well, these are my suggestions. Feel free to comment them (using this format please: "5) Art: ", so that I/others can identify better what was commented). Hope I didn't offend anyone out there.
EoF.BlackDoom;
Kimbo
#39
eek..thats..alot..well remember...Darky is the onl one who can touch the sites scripts and change stuff so..um..ja..
Maps/Spells - Delete uncommented maps with a very low dl count Skins - 85% compression on uncompressed blps, but this would be hard to automate I guess Icons - BLPPaletter! Will reduce size by 70+% iirc Models - MDXSquisher! Another 30% or so reduction in the compression
Well, let Darky be the one, but he is unreachable. I gave him like 2 PMs by now, Daelin and VGsatomi keep on telling me that Darky has some "trouble" with checking out this site...
You'd think that if I'd try to contact him, would he return an answer?
He didn't even read my PMs, not to mention reply to them...
And I do not agree with lowering the quality of BLP files. What exactly does this magic BLP Paletter do to those files anyway? How can it be better than ZIP/RAR archiving algorithms?
Another idea: let's use UHA for uploading packages. I just wonder if they could automatically open the files on server...
They'd still help since this site zips all resource and zip compression will have the same effect to paletted BLPs and squished models as the MPQ compression.
i suppose the squisher would work, but since the BLPaletter operates on BMP and TGA files, the fact that you have to submit BLP files makes it useless for this purpose
Hemlock
#43
Well people can always submit their work on epicwar.com, wc3anvil.com, hiveworkshop.com and maps.worldofwar.net and wc3cam,paigns.net with an approval. overall I guess this is gonna cost some people to leave the site and visit others.
Being given the fact that VG mentioned all upload operations have been halted for now, I suggest putting an end to these "Let's see what we can upload now?!" trials.
After all, we should be thankfull that WC3S hasn't been "killed" the way DeskMod has. At least, we don't get a 404 when trying to connect to WC3S. Plus, what if the provider finds this out and has an "ugly" reaction?
So, please, everyone make your own purge, try either to host your old stuff to some other host or delete those files of yours who you find ungly or those who haven't been seriously downloaded. After all, those are your files; you are the best people to tell if they are good or bad.
As I said, no one is forced to delete anything; I'll give an example in 1 hour or so.
It seems that there is no way through this dilema.We should purge all outdated files and start again,fresh.
.
