Hard Light Productions Forums
Community Projects => The FreeSpace Wiki Project => Topic started by: Black Wolf on July 11, 2012, 07:25:16 am
-
OK, so there's that thread in Modding that is trying to be a kind of duplicate for this page on the wiki - essentially a big thread with all the ships on it. Now, I personally am not a fan of the idea, for reasons brought up in the thread, but one thing that was brought up in the thread was the fact that the User Made Ships page on the wiki suffers from the fact that it's somewhat too complete - there're a lot of mods on there that are very old, and not up to the standards of modern releases, but there's no attempt made to differentiate these old, (often poorly) tiled and generally unpleasant ships from the newer, nicer ones.
I considered a rating system a while back (there's a thread on here somewhere) but that generated way to much hate to ever be viable. So I started thinking about a sort of "badge" system. You could have a series of simple badges (I've chosen letters for simplicity) to represent the various attributes that differentiate modern, FSO optimized models from retail ones. The more badges a ship model has, the more optimized it is for FSOpen, thus giving an at-a-glance idea of the quality of a model without any subjective judgement on anyone's part.
It's probably easier to understand if you see it, so check out the mockup in the sandbox (http://www.hard-light.net/wiki/index.php/Sandbox). In this example, there are three badges "H" for "High Poly", U for "UV Mapped" and N for "Normal maps" (Note that the attributes don't correspond with the ships linked to, it's just a mockup so people can see how it would look). The actual page would have a little legend explaining the system, obviously, and I'm not married to these badges - there could be additional ones I've not thought of, or other attributes might be better to use as basic differentiators. I've also considered the possibility of a single "Gold Star" Badge for mods that fulfill all the criteria, which might be important if there are other badges to be added (to keep the width down). Another possible badge might be a"Q" - possibly in a different colour - meant to indicate "Quality", which would be given to mods that don't necessarily include any or all of the attributes that get badges, but nonetheless are considered high quality mods. I like the idea of this badge because it's pretty obvious to anyone who looks that some retail models have aged much better than others, and that should be recognised when applicable, but it does introduce a subjective component to the process, which might be undesirable.
So, opinions on the idea? Might it make User-Made ships too cluttered, or would the clutter be worth it? Should we implement the changes? Can you think of ways to improve it prior to implementation? Any opinions or thoughts would be welcome. :)
Oh, and while typing, I also thought about the possibility of possibly using a "C" badge for "Cockpit" - to be applied in the case of low poly fighter models that have been "HTLed" by the addition of a cockpit without changing much else.
-
I can go with his idea. badges I would suggest are
(HP) High Polly
(NM) Normal Maps
(UV) UV Mapped
(MD) Mod/Model Dump Only Download
(MV) Multiple Versions
(IV) Incomplete Version (missing or faulty table for example)
(MVP) Uses MediaVPs assets
-
This is a good idea.
However, just as I mentioned in the topic that spawned this idea.. Who is going to spend all the time updating the Wiki page if this were adopted?
-
Who
assessessessess rates the quality of a model too? Everybodys tastes are different -
Different strokes for different blokes as the saying goes.
I'd suggest the author of the ship maintains his/her own page, failing that. . . . Do we have a wiki team :nervous:
-
Well in Headie's proposed set of badges, none of them have anything to do with "rating quality" (except maybe high-poly). The rest are all factual, and very useful.
-
I wouldn't put down the "High Poly" badge, as what's considered high-poly today will be obsolete in... like 2 years?
You could, however, make a badge that denotes how many poly's it has, like a >1K, >10K, >100K, etc.
-
I think z64 has a good idea personally. It's a much more future proof solution.
-
I would have to agree it's the better way of doing it
-
I can go with his idea. badges I would suggest are
(HP) High Polly
(NM) Normal Maps
(UV) UV Mapped
(MD) Mod/Model Dump Only Download
(MV) Multiple Versions
(IV) Incomplete Version (missing or faulty table for example)
(MVP) Uses MediaVPs assets
Many of these are probably not so relevant for the actual User-Made ships page itself - maybe on the individual pages for specific mods, the way Wookiepedia uses icons at the top of every article to establish the time period the subject is in. The aim here is to quickly differentiate between SCP optimized, recent mods and older, generally lower quality retail mods - stuff like multiple versions and modpack only isn't really related to that though. The "Incomplete" tag might be useful, though.
This is a good idea.
However, just as I mentioned in the topic that spawned this idea.. Who is going to spend all the time updating the Wiki page if this were adopted?
The same people who wrote it in the first place. :p It would be an ongoing project, but I'm sure that people would rise to the challenge, even if it was over the course of several months.
I wouldn't put down the "High Poly" badge, as what's considered high-poly today will be obsolete in... like 2 years?
You could, however, make a badge that denotes how many poly's it has, like a >1K, >10K, >100K, etc.
I used "High Poly" because people won't necessarily know what "HTL" means, but the criteria for "High poly" would basically be any ship designed from the word go for post HT&L poly limits, and therefore not retail compatible. That'd mean that things like retail fighters with added cockpits wouldn't get the "High Poly" badge (which might justify the separate "C" badge for cockpits).
-
I suggest these icons be added through templates, as they are much easier than copy/pasting code.
For the list, I also propose a tilemapped (T+) and non-tilemapped (T-) icons, because I see people are crazy about those.
-
Black Wolf I think a reread is in order here mate ;).
My suggestion is meant to compliment your suggestion, implemented in the same way as your example but provide additional useful info for modders, for example a novice might not want to have to debug a ship with a faulty table or someone on a tight download limit might not want to download a large mod just for a couple of ships.
As for High Polly vs HTL, z64555's suggestion was for an indication on polly counts which is a lot less subjective than "High Polly"
I suggest these icons be added through templates, as they are much easier than copy/pasting code.
if this is doable then it is probably the easiest way for the users and to maintain consistency.
For the list, I also propose a tilemapped (T+) and non-tilemapped (T-) icons, because I see people are crazy about those.
certain level of ignorance here but is it possible to have a non UV mapped non Tile mapped ship? I know a hybrid is possible so perhaps having either a hybrid icon or a separate tile map icon that can be used at the same time?
-
I was referring to completed ships. A non-UV-mapped ship is by definition incomplete.
[EDIT]
Right, I have made the templates and edited the sandbox. Currently, the Andropov and the SOC Orc uses templates. I kept the rest there.
-
I suggest these icons be added through templates, as they are much easier than copy/pasting code.
For the list, I also propose a tilemapped (T+) and non-tilemapped (T-) icons, because I see people are crazy about those.
Good idea on the Templates - I did it with the image tag because the sandbox example is only a quick and nasty mockup, but templates will be significantly tidier and easier. As for tilemapped +/- icons, that's the point of the UV-mapped Icon - Headdie's right to point out that ships have to be one or the other, and I wanted to focus on the positive attributes, so that the more badges a mod has, the more modern and SCP optimized it is.
Headdie: Are you talking about Icons on the User-made ships page or on the individual mod's page ala wookiepedia? See, the problem I see with the page as it is now is that there's no visible way to determine which mods are good and bad (or, a better term might be which are modern and which are outdated) until you click on them and look at the picture, which is a problem for some of the categories with dozens of entries. Adding these badges will solve that problem, by giving an at-a-gance idea of the quality (or modernity, if you prefer) of the mod. More badges = more recent mod. Adding those other categories might be useful to certain specific modders, but if it also adds badges to mods that wouldn't otherwise get them, and that eliminates the at-a-glance concept - you have to look and see which badges each mod has, and whether they're relevant to the quality, or just related to its level of completeness or availability outside of large scale modpacks.
-
What I am on about is the User Ships page, implemented something like in your sandbox example with the icons appearing in the link name.
-
"Missing" table entry does not mean incomplete!
Tables can be made in seconds.
I never use the tables that come with models anyway, except maybe as a reference because there is a 70% chance that whoever made it doesn't know what they're doing and messed something up anyway. (or they use some deprecated flags etc that throw up a bunch of warnings, missing weapons etc...)
This is also why I don't include table entries with my releases (but they're not incomplete!)
Including a table entry encourages people to just copy/paste it into their mod without checking for errors, balancing, etc. Which is poor practice IMO. If you're going to have to do that anyway there's no real difference starting from, say, a retail table entry for something of a similar size and then tweaking it as necessary, which should be required anyway.
Then again, you should be doing the same thing with models, checking for POF errors, etc. Because you can't really trust anything at all. :P
Thus the entire concept of a "completeness check" is flawed, as one should check for that themselves anyway.
my $0.02
-
The badges shouldn't be viewed as a "completeness check," rather, more of a quick manifest of what the uploaded file has. The idea is that the badges allow potential... shoppers... to see what the file has at a glance vs. downloading the file, opening up in pcs2, and manually seeing what goodies it has.
Yes, they'll still need to do the manual check, but again the point of the badges is to speed up the selection process.
Also, as an added bonus, model makers can view their "competition" and perhaps be more motivated to put more effort into their model. :drevil:
-
Then I recommend fault tags such as POF errors (which are in anywhere between 60-70% of existing released models, I kid you not).
Be it missing MoI's, faulty smoothing, faulty lighting, or collision issues; missing/poorly placed paths, missing debris/LODs, or faulty subsystem data.
The thing is, it's not really going to motivate anyone because most people don't have a sodding clue what they are doing, and thus do it all wrong (this applies to 95% of the assets released before the collada import/exporter, and even a while after, when it would occasionally drop polies and whatnot).
If you're going to use custom assets you might as well learn to make your own...saves you debugging nightmares ^^ (this is from experience, if I didn't know the ins and outs of the production/conversion process I would have murdered people when chasing a few bugs with assets in DE >.>)
I guess most people would only be interested in "works well enough 90% of the time" instead of really getting it bug-free. I guess I should apologize for sounding so...negative/disillusioned... but hey, such is reality.
-
Or anything that has errors of some sort gets a single tag. Bam. Done.
Whether or not you use the tables that come with ships is irrelevent. A table entry with a ship will show the user the intended stats (speed, maneuverability, etc) as well as subsystem data. Generally it's just nice to include one. Especially since creating a modular table is so easy, as you "nicely" pointed out.
However, it doesn't matter. The proposed tag is not a tag for "missing table" it's a tag for "missing data" and thus all you're little complaints fit right in it.
-
It does matter. What qualifies as missing data?
If a table is missing gets the tag, same with a ship that has no hierarchy in the POF whatsoever...then the tag is worthless. One isn't missing anything at all really, while the other requires you to go back into a modelling program. If they all have the same tag then it's meaningless, because everything will have it.
You could just ignore the table side thing anyway, because not once have I ever used the table that came with the model without heavily editing it. In fact, I recall using an included table as a reference for subsystems only to find out that there were 4 to 5 other ones on the POF (subobject based), that weren't listed and caused FSO to throw errors. If there wasn't a table, I would have checked and it would have saved me more time even. The speeds/maneuverabilities for what I make don't work outside of it, really, so unless you have the same flight model as I do, it is useless to everyone else; I'm not going to re-imagine what something's role should be just so someone MIGHT use it. That's absurd. Including a table is a pointless venture - I wouldn't use one, and I wouldn't trust anyone who would!
Perhaps they should be separated by what you need to use to "fix" it.
ie. its fixable PCS2-side, or you have to bring it back into Blender/Max/Whatever to fix...
But that goes back to the "negative" thing, don't exactly want to call people's hard work bad, you know?
You know what, do whatever you want. I just realize that I don't care I won't use it anyway. Just like how I don't trust anyone to make a bug-free model, I wouldn't trust anyone checking them to catch all the possible faults. Which boils down to the fact that I'll have to examine everything myself anyway.
Well, that was a waste of time and words. Sorry for wasting yours.
tl;dr **** it what do I care
-
Most of that sounds like "I don't use FS-like flight stuff in my mod, so most released tables don't mean anything to me." Whereas most of the mods on HLP do base their stuff in general FS, and so the tables would be useful, even as a starting point. Also, including a tbm is just good practice given that it's a ships database and not a models database. Even if the tbm is based on a different flight model. You don't have to convert anything. Your model from you mod can include a tbm that has your ship's stats and it'll still be a complete set.
But hey.. your world sounds cool too... you know, with the way that you don't trust anyone to do anything as bug-free as you... :doubt:
Needlessly hostile posts are needlessly hostile.
-
tl;dr **** it what do I care
why are you arguing the toss then? you manually check and rebuild the ship anyway? fine, ignore the flags and do as you do anyway no one is stopping you.
also I for one have used the supplied table often in the past and while some are badly borked many just need a few seconds to fix. Not to mention that tables was used as an example, it could also be missing textures or as you say a host of other stuff, what it does provide is information, that while non specific, does warn novice modders and modders looking for something quick to use that this ship needs work to get it usable and where is the problem with that?
you want a detailed breakdown of each and every model's faults? go through each one and write up a detailed report in the relevant ship page, but right now we are discussing an at a glance guide to each ship which means it needs to be kept as stupid simple to understand as possible.
-
But hey.. your world sounds cool too... you know, with the way that you don't trust anyone to do anything as bug-free as you... :doubt:
When did I ever say that I trusted myself?
I don't trust anything...because experience proves that it just trusting something to be problem free just leads to debugging nightmares oh god the debugging nightmares.
Even when I am doing FS-like flight mods I still basically re-do the entire table, or at least check every line of it to make sure it's in working order, followed by a bunch of tweaking to make sure everything has some semblance of balancing...
I'm paranoid, okay? because I still have those nightmares.
tl;dr **** it what do I care
why are you arguing the toss then? you manually check and rebuild the ship anyway? fine, ignore the flags and do as you do anyway no one is stopping you.
also I for one have used the supplied table often in the past and while some are badly borked many just need a few seconds to fix. Not to mention that tables was used as an example, it could also be missing textures or as you say a host of other stuff, what it does provide is information, that while non specific, does warn novice modders and modders looking for something quick to use that this ship needs work to get it usable and where is the problem with that?
you want a detailed breakdown of each and every model's faults? go through each one and write up a detailed report in the relevant ship page, but right now we are discussing an at a glance guide to each ship which means it needs to be kept as stupid simple to understand as possible.
I don't know. A stupid at-a-glance thing seems like it would be entirely misleading, and encourage laziness.
That is bad, when modding one must have CONSTANT VIGILANCE and FREAK OUT AT EVERYTHING THAT COULD POSSIBLY GO WRONG.
Even then you'll still run face-first into horrors beyond imagine.
The unholy bastard spawn of codethulu and we who know not where we are treading.
...im scared to sleep alone...
-
right now we are discussing an at a glance guide to each ship which means it needs to be kept as stupid simple to understand as possible.
Quote'd for truth.
"CONSTANT VIGILANCE" is something the modder is responsible for, not the Wiki. The Wiki is responsible for accurate information.. of which these tags would provide with efficiency.
-
Sure I guess...that works.
-
OK, I've done all the preliminary work and (barely) started adding icons. I'm under no illusions about how big of a job this is going to be, and I'll do it myself eventually, but the more the merrier. I've added a couple more icons, but they all have templates, so they're easy to add. The only slightly complex one is the "Incomplete" Icon - following Droid's... rather unusual issues with the wiki, I've added the capability to link to a separate page (http://www.hard-light.net/wiki/index.php/Mod_Incomplete_Reasons) and explain why a mod is "Incomplete" using the following syntax:
{{RI|Ship=SHIP NAME HERE}}
Just remember to add the relevant mod and explanation to that page.
[EDIT] Simplified the {{RI}} template.
-
OK, so progress is moving along, but very slowly. Hopefully, this will speed things along.
Welcome new editors!
The Freespace wiki is currently in the process of adjusting the User-made Ships (http://www.hard-light.net/wiki/index.php/User-made_Ships) page with a series of icons, designed to give an "at-a-glance" idea of the quality and modernity of a model to speed up the process of choosing high quality, SCP compatible mods for use in new campaigns. The process isn't complicated, but there are a lot of mods on the page, so we're looking for volunteers to help out. It's not hard, and we're not expecting a big commitment of time. All we're asking is that everyone do a few, maybe five to ten ships each. This shouldn't take long, probably only ten minutes or so, but if thirty or forty people get involved, we can have this whole project knocked over in no time. Of course, people who want to do more are welcome to do so. :)
OK, so how do I help out?
It's really easy.
Step 1 - If you're not already, sign up as an editor on the Freespace Wiki (http://www.hard-light.net/wiki/index.php/Main_Page).
Step 2 - Head to the User-made Ships (http://www.hard-light.net/wiki/index.php/User-made_Ships) page, and check out the work that's already been done.
Step 3 - Choose a few ships, click on edit and, following the established systems, start applying icons. It's all in plain text with some wikicode, but the templates are very easy to figure out.
Step 4 - If you included any "Incomplete" tags, edit the Reasons (http://www.hard-light.net/wiki/index.php/Mod_Incomplete_Reasons) page to include details on what was missing.
And you're done. See, wasn't that easy?
Possible Questions
What do the icons mean?
There's an explanation of each icon at the top of the page. Mostly they're self explanatory, but just in case:
H = HTL. Use this for ships that exceed retail polycount capabilities. It's not meant to distinguish between very high poly models like the Blizzard (http://www.hard-light.net/wiki/index.php/HEF_Blizzard) and regular high poly models like Selkie (http://www.hard-light.net/wiki/index.php/GTF_Selkie).
U = UV Mapped. Most fighters and most modern capships don't use tiled mapping, and so they'd get this tag. There are hybrids, but as a general rule if any part of the ship has been UVed, it will probably get this tag.
N = Normal Maps. Pretty straightforward, if the DL (the one linked on the wiki) includes normal maps, it gets this tag.
C = Cockpit. Any ship that has a modelled cockpit. This is in a different colour because there are a few ships (like the Stentor (http://www.hard-light.net/wiki/index.php/EAF_Stentor)) that have cockpits while no other part of the ship has been upgraded for HTL. So while the model will exceed retail capabilities, it doesn't really deserve a full "H" tag.
I = Incomplete. Use this if the ship is missing something or in some way unusable - most commonly, this one will apply to ships released without table files, but sometimes things like MoI are missing too.
What do the strange codes mean?
The wiki uses templates to simplify the process of adding the same wikicode over and over again, designated by text in twinned curly brackets {{like this}}. The templates we use here are very straightforward - two letters, the first designating colour, the second designating the letter on the icon. Thus {{WU}} will give you (http://www.hard-light.net/wiki/images/UMS-WU.png), a White U, {{BC}} will give you (http://www.hard-light.net/wiki/images/UMS-BC.png), a blue C.
Why is {{RI}} different?
The incomplete tag is a bit different because it includes a link to an explanation of what was missing and (occasionally) how to fix it. The syntax is very straightforward however:
{{RI|Ship=SHIP NAME HERE}}
Make sure you use exactly the same ship name on both the template on the User-made Ships page and the heading on the Reasons (http://www.hard-light.net/wiki/index.php/Mod_Incomplete_Reasons) page, or it won't work properly.
Anything I need to watch out for?[/i]
The only thing to note is that accuracy is pretty important on things like this. Sometimes it's obvious from a ships picture whether it's been, for example, tile mapped or UV Mapped, but it's not always obvious if it has, for example, normal mapping, or exceeds retail polygon limits. If you're unsure, download the ship and check.
-
I think it's important to organise the modding board too. Sorry please don't hurt me! :shaking:
-
Should there be a tag for ships which *are* retail compatible and complete? That might make it easier to tell when those ships have been checked, if they don't use UV mapping.
-
I think it's important to organise the modding board too. Sorry please don't hurt me! :shaking:
How do you think it should be organized?
-
How do you think it should be organized?
It's funny you should ask that. (http://www.hard-light.net/forums/index.php?topic=81355.0)
-
Aren't we running in circles here ? This thread here is supposed to take care of the issue that led you to make that other thread there...
-
Question: To qualify for the "cockpit" tag, a ship must have a separate cockpit pof file and it must be linked in the .tbm, correct?
Additional: How do we decide if a model is high-poly or not? Is there a poly count feature in PCS2, or do we just estimate? nvm, found it. And how does one with no modeling experience determine if something is indeed UV mapped? (example: GTF Raziel (http://www.hard-light.net/wiki/index.php/GTF_Raziel))
-
Cockpit tag should mean modelled internal cockpit that can be used with "show ship", or an external cockpit POF.
Also it seems like a lot of things are only missing table files (because, I guess, many modders agree with me that if you're modding you should be able to make your own table files). I propose we make it something like {YI} (yellow I?) for just missing (or faulty!) table file. Then the Reasons page would be far less cluttered. Yes I'm still on about that, because I still don't see that as incomplete... :P There's never a reason to include a "how to fix" for a missing table file, so linking to the reasons page is kind of redundant (plus it'd save everyone some work)
Also, FYI, all of Taristin's Lizards/BekTah had some weird POF shield collision/smoothing bugs. I had to reconvert all of them for DE. If you get them from DE they *should* be bug-free, but I can't vouch for the original models. Might want to note that on the Reasons page. Same with a bunch of Aldo's models that were put through with the Max converter (the Selkie, amongst a few others). I'll see if I can come up with a list of assets with non-obvious conversion-based issues.
-
I just added some badges to the Vasudan fighters :)
-
Aren't we running in circles here ? This thread here is supposed to take care of the issue that led you to make that other thread there...
I've never heard a good argument against doing both.
-
No one's stopping you from trying to create a thread on the modding board... My time will be spent on the Wiki because it's far more versatile than a thread post that only you can update. Also, the modding board already has like 8 stickied topics that my eyes naturally ignore now.
Regardless, there's no reason to debate that issue in this thread. This thread is about a Wiki formatting method that is now in-progress. Just because it's being worked on doesn't mean you can't make your thread either.
-
There was a miscommunication about the issue I brought up. I have clarified it in the relavent thread and will no longer post about it here.
-
ok I am doing the Lethe to the Agias in fighter craft for now. will do more tomorrow. Somebody might wanna check a few of these to make sure I did them correctly. Also not sure about incompletes and missing table files.
the link to the EAF Styx (http://www.hard-light.net/wiki/index.php/EAF_Styx) for download and following that takes me to media fire and the file has been deleted
same with the FTF Mig (http://www.hard-light.net/wiki/index.php/FTF_Mig)
also for some of these files, what would I need to do so I can download just the one model and its parts, instead of a "pack" of models? What I mean is do I make a media fire account or something and link the separated files to the wiki pages?
Also there doesn't seem to be a page for the shivan corvete Armaros featured in the ED modpack :Edit: looks like several other ships from that modpack are missing, including the Atlantis (cruiser), Barbados (Corvette), Evander (Bomber), Khalan (Bomber), Krios (Fighter), and the Sol jump gate.
Edit: what do I need to know about creating a page for these?
-
Hi again, I think the second part of my question got lost up there, so I'll ask again:
What exactly makes a ship qualify for HTL status? Total number of polies, I would guess, right? How many is enough to qualify it?
And how can somebody without modeling experience tell for certain if a ship is UV mapped or not?
-
What I was told when I got IRC and asked was that if the texture repeats itself it is tile mapped. I've been downloading the files and checking for the textures as well.
-
So.. as I've been using the Wiki with the icons (even though incomplete thus far).. it's become very useful. Definitely worth the effort. I'll be doing my part here soon.
-
Regarding the FD Vexor:
It technically is a hybrid and UV-mapped but I kind of refuse to accept giving a texture-whoring abomination like it a {{WU}} tag as it would de-legitimize the entire tag (hurr lok I use more textures than a tilemapped ship and I still get the {{WU}} tag), at least until that VexorUpdate gets finsihed. :P