File Archive Work - COMMUNITY INPUT APPRECIATED

Status
Not open for further replies.

Chernobyl

Sr Member
I've recently spoken to a few of our more high-profile content creators, and also to Asgardianhammer, who's in charge of our Division Identity Guidelines. regarding the File Archive and the content within it.

I've been toying with the idea of combing through the Archive and removing less-accurate files. This doesn't mean that I'll be single-handedly going through the Archive and purging any files that don't meet a highly-scrupulous and unreasonable quality expectation - I value the contributions of every modeller that's made the effort to produce content for the community. Nor does it mean that only files produced from game resources will be maintained in the Archive - custom-made content can sometimes exceed the quality of our raw game assets. With that said, now that our Deployment process is active and running, it's worth looking at our resources with a critical eye and ensuring that our resources are of the highest quality we can provide.

Put simply, my logic for this project is as following: higher-quality files result in higher-quality costumes. Again, this doesn't mean I'm going to be combing the Archive and removing all files that don't meat an unreasonably high expectation. Nor does it mean that the files we offer will gradually become more and more complex and difficult for our newer members to use - I still want to try and keep our resources accessible to members of all skill levels. However, in the interests of making sure that our available content ensures our builders are working with only the finest-quality materials, it means (again) looking at files with a critical eye and saying 'this file isn't especially game-accurate'. It's worth considering files to be 'community-approved', such as certain foam files or even RobotChicken's Mk VI remodelling project - certain files that are used so often by the community that they've become a staple standard for a certain costume type.

Looking further down the line: I'm hoping that the forum upgrades Art Andrews and FANGS have been mentioning recently will bring with them a revamped Archive system, that will give me a broader set of permissions to better enable me to filter and sort the content our community produces. One of those tools will (hopefully) be the ability to remove Archive categories - my plan in this instance is to move away from files sorted by title (Halo: CE, Halo 2, Halo 3, etc) and instead into faction and generation (Covenant/UNSC/Forerunner, Mk IV/V/VI/G2). This should (hopefully!) begin to remove some of the issues the community has been having with locating files, by making the files more easy to locate. For example:

Current: Archive > Halo Universe > Halo 4 > named armour set
Proposed: Archive > UNSC > Mk IV/V/VI/G2 > named armour set

This would have the added benefit of consolidating the Halo 4 and Halo 5 armours into one location - currently, several people have found confusion in why I haven't added returning Halo 4 armour categories, such as Scout and Recon, to Halo 5.

I'd also like to move away from separate 'OBJ Archive' categories, and instead include the raw assets for a certain set in with the rest of the files relevant to that set. For example:

Archive > Halo Universe > G2 > Mk VI (Multiplayer) > (Mk VI (Multiplayer) OBJ Files Pack) / Helmet Unfold File / Torso Unfold File / Forearms Unfold File)

This should reduce the number of 'I can't find Asset XYZ! Where are they?!' requests - modellers and unfolders looking for raw files to work on would be able to simply look up that set to find the files they need, rather than hunting down the files in a different category.

Please let me know what you think, and provide input for anything I can do to streamline the Archive and provide the best content for our users. Again: the higher-quality our content is, and the more accessible it's made for our newer users, the more we'll see some excellent-quality costumes going up.
 
Last edited by a moderator:
Took me a minute to wrap my brain around it but I like it. Looking good. And I see where you put them back up but yes please keep the OBJ's where they can be semi found.

Good work and Thank you Chernobyl.
 
Upvote 0
Took me a minute to wrap my brain around it but I like it. Looking good.

As I said, it'll take a while for the older members, who have gotten used to the old system, to adapt to the new system. Even I myself still find myself stopping for a second and going 'uhhhhhh...' before realising and going ahead with what I need to do.

And I see where you put them back up but yes please keep the OBJ's where they can be semi found.

They're about as visible as they can be at this current point - my main issues with the Archive now are with formatting, mainly. I'd prefer to have the splash page laid out more like this:

[FACTION 1]
(Description of faction)
Sub-Categories:
- (Thumbnail A) Category A
- (Thumbnail B) Category B
- (Thumbnail C) Category C
- (Thumbnail D) Category D
- (Thumbnail E) Category E

----------

[FACTION 2]
(Description of faction)
Sub-Categories:
- (Thumbnail F) Category F
- (Thumbnail G) Category G
- (Thumbnail H) Category H
- (Thumbnail I) Category I
- (Thumbnail J) Category J

Instead of the system we currently have, which is:

[FACTION 1]
(Description of faction)
Sub-Categories:
- (Thumbnail A) Category A - (Thumbnail B) Category B - (Thumbnail C) Category C- (Thumbnail D) Category D - (Thumbnail E) Category E

The current system is quite jumbled, and from the splash pages it can be very difficult for a member to navigate without artificially enhancing the font size on their browser. If the font size could be increased by one point (or two, at the most, without breaking the page formatting), and categories listed on their own line as opposed to as a single chunk of text, things might be a little better.

I'll put together a quick image mock-up later on to show off my point - it's a little frustrating that I'm not invited to Staff Meetings to address these concerns directly and get my needs recognised without having to go through several middle-men delivering messages for me, so that may be something we address later on down the line.

As for the OBJ Archives themselves - they're quite low down in the Archive, just above the Non-Halo section, so I may re-organise the categories to have them higher up the page. They'd be a little more visible.

Good work and Thank you Chernobyl.

You're welcome. Keep the suggestions flowing in!
 
Upvote 0
As an alternative to listing a polycount for models, which may not accurately reflect detail or difficulty (eg where the model is curved), maybe list part count or page count (which would be (relatively) easy to extract from a .pdo) or maybe fold count or tab count (harder to extract, obviously less useful for foams) could give an idea of the difficulty in making a particular part with pep, and allow an easy comparison of different versions of a particular armour or weapon.

For example, UNSC>Weapons>UNSC Rifles currently contains no less than seven different versions of the Assault Rifle. Now, while some may be picky enough to only want, say, the Reach design, in which case it's just a matter of pep vs foam, others may just want an Assault Rifle. A parts count or a tab count would give a quick way to make comparisons between items' build difficulty and find their ideal compromise between look and difficulty.
 
Upvote 0

That's a fine suggestion in theory, but in practise it's a little more difficult to implement.

The difficulty of any given file is relative to the skill of the person assembling it - I can handle some pretty complex files without issue, whereas a newer member might have difficulty with even the more basic files. File difficulty gradings were thought of some years back but ultimately the idea didn't stick.

It's better to leave the 'difficulty' of a file as subjective to the person working on it.
 
Upvote 0
That's a fine suggestion in theory, but in practise it's a little more difficult to implement.

The difficulty of any given file is relative to the skill of the person assembling it - I can handle some pretty complex files without issue, whereas a newer member might have difficulty with even the more basic files. File difficulty gradings were thought of some years back but ultimately the idea didn't stick.

It's better to leave the 'difficulty' of a file as subjective to the person working on it.

Oh, certainly, but a quicker way to check "Oh this model is 600 parts, and this one is 140. 600 parts would take weeks if not months just to cut out, so I'll go with the other one thank you very much." could be pretty useful.
 
Upvote 0
Oh, certainly, but a quicker way to check "Oh this model is 600 parts, and this one is 140. 600 parts would take weeks if not months just to cut out, so I'll go with the other one thank you very much." could be pretty useful.

Again, a decent idea, but still subjective. People should be able to tell from the thumbnail how complex a file is, the difficulty is still relative to the skill of the person assembling it - and, honestly, I don't want to have to go through a few thousand files figuring out how many parts each file has, and listing it in the file description.
 
Upvote 0
Again, a decent idea, but still subjective. People should be able to tell from the thumbnail how complex a file is, the difficulty is still relative to the skill of the person assembling it - and, honestly, I don't want to have to go through a few thousand files figuring out how many parts each file has, and listing it in the file description.

I'd imagine it could be done automatically, perhaps with a script extracting the partscount from the .pdo. Now, I'm not super knowledgable about the .pdo format, but since pepakura shows the partscount in the corner, I'd assume extraction would be possible.

And to be fair, if, prior to me having downloaded them, you showed me the thumbnails of the 142- and 590-part MkIV chests and asked me which one I thought had more parts, I would probably have thought the 142-part one had more parts, with its visible coloured lines, and even if I'd guessed right, I'd never have come close to the disparity in complexity.
 
Upvote 0
I'd imagine it could be done automatically, perhaps with a script extracting the partscount from the .pdo. Now, I'm not super knowledgable about the .pdo format, but since pepakura shows the partscount in the corner, I'd assume extraction would be possible.

I'd have to download the entire Archive, have the tool written to enable me to perform that function, then individually input each value into each file description - there's no way to be able to do it automatically, and I highly doubt that such a trivial thing would be worth the time of the staff who actually work with the back end of the site. In long and short: too much work for not enough output.

Fine idea - tough to implement, not especially required.
 
Upvote 0
Status
Not open for further replies.
Back
Top