Fallout Wiki
Register
Advertisement
Fallout Wiki
Forums: Index > Wiki discussion > Model Viewer Discussion

First off, hey all! I've been "missing" for a few months or so - but mostly I've been doing mad scientist stuff.:p Which brings me to the topic at hand. If you haven't been checking Twitter, or haven't talked to Jspoel, I'd like to point your attention here. If you click on the infobox, and your browser supports WebGL, you should see the progress of my current project. For those of you who can't see it - it's a model viewer, that's no different in concept than what you'd see in the GECK or NifSkope - only, in this case, entirely web based.

But before I progress any further on this project, with the intent on adding it to Nukapedia, I need a course of action. And to get that course of action, I need your opinions and suggestions on the matter. After all, most of you have put in a lot more time and effort into this site, than I have. If anything, I'm just a glorified interior decorator. :p

What follows are a few key points I need input on, so we can all discuss, and come to agreement on them.

Importance/Focus[]

To put it simply: This is a wiki covering the Fallout universe, which exists almost entirely in the games that have worn its title. The last two of which, and undoubtedly future releases, have been made in true 3D.

So the question is, how much value - how much importance to the readers, would the addition of this feature have? In other words, how would the ability to see the items, objects, and (eventually) clothing/NPCs, as they appear in game, from the comfort of Nukapedia, affect the popularity and traffic on the site?

This should dictate the necessity, accessibility and notice-ability of the feature in question.

Method[]

Currently this feature works on the test site, by overriding the larger view of the infobox image. The consensus so far, one that I ultimately agree with, is that this isn't very viable. So the question remains, what would be a good method for accessing the viewer window?

One method, would be to have it work off of a gallery thumbnail - this wouldn't require the need to find a place for something; but on the downside - it would be suffering from the same issues the infobox image did. Namely - when a user clicks on a thumbnail, they expect a larger version of that image - and not completely different media. That's why video thumbnails tend to feature a "play" icon on them.

Another, would be to add a button, somewhere on the page, that simply states "View in 3D". While this would require figuring out a place to put it, on the layout, it's purpose is immediately clear, and takes up less layout space in general, than another thumbnail.

But those are just two options - I'm sure there are other possibilities, so if you think of one, please share. Otherwise, please state your preference. Displaying the viewer directly on the page however, is not a valid option. Too much of a performance hit, to force it on anybody who visits the page. Regardless of the method of accessing it, the popup window, is likely the best overall method of viewing it.

Data Storage/Organization[]

The original plan of this project, was to create not just a model viewer; but one that could be run "natively" within the confines of a Wikia site. The downside is, that there's quite a few limitations on everything from page size, to accessing images that were uploaded to the site.

In order to compensate for these limitations, I was forced to store the actual .nif file, and its textures (in png format), in (base64) text format, on individual pages. The downside of this, is a bunch of pages that look similar to this. Now, obviously this isn't something that would have a point to be seen by the users.

So, in the interest of keeping things organized, and having a bit more control, I'd first suggest a custom Namespace for these things. Something like "Data:" or "ModelData:". That way, (hopefully), these things could be kept out of the public eye, and not hog up the "recent changes" feed.

Beyond that - is naming conventions. Currently on the test site, they're merely stored using names that are "flat paths". For instance, the above nif file, would be located at /Meshes/Weapons/2handrifle/plasmarifle.nif in the game's data, and on the test site, the page name is Meshes-weapons-2handrifle-plasmarifle.nif. So one option would be storing the page like:

/wiki/ModelData:Meshes-weapons-2handrifle-plasmarifle.nif

But, since pages support paths, this should also work:

/wiki/ModelData:Meshes/weapons/2handrifle/plasmarifle.nif


Doing things like this, will reduce bloat a bit, by allowing multiple models to use the same textures, as they do in game. At any rate, some form of consensus is needed - to make sure that sanity and organization prevails.

One final note: since all files involved are "translated" in the same manner, and the result is the actual file data - anybody that has access to the games files, should be able to contribute, using a site similar to this. The general rule of thumb, similar to the result of Bot-Rewrite, will be to wrap "pre" tags around the data itself. This way, regardless of the file size, it will only appear as a single line on the page itself. For the textures, currently only png are supported - so the .dds textures would have to be converted first to that format. Some additional modifications would be needed for normal maps - as the game uses the alpha channel from those files, as a separate texture type.

Comments, Questions, Concerns, and Opinions[]

All are welcome, and desired below.

I would like to see this on the wiki ASAP. I think it should be in the Gallery, maybe taking up about 1/2 of the standard page width, inside a template box with a link to a page outlining known tech issues and explaining what it is (for those who cant' see what is supposed to be there. Agent c (talk) 15:54, January 12, 2015 (UTC)

This is all very impressive, Digital! I've never seen anything like it on any other wiki, and it could become a major feature of this wiki. People will be very interested, and what you've done with the plasma rifle is one great example! (You've just improved its quality to the extreme by adding a few more .png textures files right?). I'm glad you see our point, that clicking on it in the infobox shouldn't straight away show a 3D model, because people expect just the larger 2D-model. But the idea of a small 3D thumbnail gave me an idea. The gallery is a good option and it may be the way to go, but I was thinking of an alternative and see if we could add an icon in the top left corner of the infobox, similar to the Pip-Boy icon you see in the right top corner. Or somewhere else slightly below it using a new parameter line. That would give it more profile. For overview pages with more items like similar clothing, the gallery can be used. For the organisation we sure can use a new namespace, ModelData is a good name. For the nif files I wouldn't use a deep branch, but give it a good name like FNV plasma rifle.nif and place it in a well named category, f.e. Category:Fallout: New Vegas weapon 3D models. Its .png texture files can be named f.e. FNV plasmarifle#.png‎, FNV plasmarifle alpha.png etcetera, and store it in a category below that. Jspoel Speech Jspoel 17:08, January 12, 2015 (UTC)
It does need testing though I think to see how it works on different browsers and mobile, and more detailed instructions for us less tech savvy users, in order increase the workforce getting the .nif and texture files uploaded. Jspoel Speech Jspoel 17:19, January 12, 2015 (UTC)
Looks awesome. I have easy access to all the models and textures everything in NV and F3 so I'll happily upload as much as needed. One question I have is about the legality of this. Would we actually be allowed to upload the models and textures to the wiki, as it places them in very easy access of the general public.JASPER//"Do you like hurting other people?"UserRichard 17:54, January 12, 2015 (UTC)
I don't see a problem with it. We've uploaded many soundfiles, dialogue files and images from the GECK. We are all crediting it and that should be good enough. Bethesda only is profiting from this. Jspoel Speech Jspoel 18:11, January 12, 2015 (UTC)
This is AMAZING. You just keep blowing my mind with unbelievably nice improvements to the visual side of our wikia. I absolutely love this. If this is legal (I'm no expert in US copyright stuff) then i think it would be super to add this to our wiki. My thoughts on how to get to the view would be to add a button on the top left image (like the pipboy one on the top right) with just a fancy "3D" icon, or a seperate line in the infobox with "Click here to view in HD", a bit like we added the dialogue files in link. - Greets Peace'n Hugs (talk) (blog) 18:34, January 12, 2015 (UTC)
Wow, all of a sudden tons of comments! :P Let's see if I can break these down a bit. First off, method of viewing it. I was playing around a bit, and came up with this idea - the menu drop down, would be used on pages that cover weapons with mods. For instance, in this case, clicking the button would show the standard plasma rifle, while there would be one for the magnetic accelerator version as well. Since it seems that each mod combination has a different model, it's one way of handling these things. Not too crazy about the color of the button in contrast to the infobox, but../shrug. Having a inset icon on the infobox image would work (modification choice could be moved to the viewer itself), I'm just concerned too many insets would start covering up the main image itself.
As far as support goes - I should have a pretty good test already enabled for checking whether or not someone's browser supports WebGL. Performance of course will vary from device to device - computer to computer, testing of course will be ideal, but there shouldn't be any issues other than slowness for those devices that don't have the performance.
And with naming conventions - it would make things a lot easier if the paths are kept the same way they are in the game archives themselves. See, the textures referenced in the .nif file, also include the paths (relative to the data folder), and this is important as the nif files themselves share textures. For instance - the Magnetic Accelerator Plasma Rifle and the normal Plasma Rifle, both use the same textures for the base. So making separate textures for each model, would just increase bloat. So it doesn't have to be deep - but then the "path" should be part of the name itself (i.e. textures-weapons-2handrifle-plasmarifle01.png)
Finally, the reason for the quality increase since the first time I shared it, was because the textures default to the 3rd person textures (i.e. what you see in the world, or in another character's hands), I merely just changed the image data, with the 1st person textures - which are about 4x the resolution. :p DulogoDigital Utopia (talk) 22:29, January 12, 2015 (UTC)

Isn't that an overkill? Sounds like a very interesting idea, but also quite much work, which only users with GECK editor can do. And not only that, they also need to know how to add these things. Energy X 18:37, January 12, 2015 (UTC)

Overkill? It's a major asset if we can get it to work over here. I'm willing to spend hours on it and motivated to add it to the wiki. I hope others as well, though I know it's timeconsuming. We'll just have to see who is willing. Anyway, any new image is already a good improvement. We start with the weapons, they are clearly the most popular. Digital can create a sort of guide with more detailed instructions. Jspoel Speech Jspoel 18:49, January 12, 2015 (UTC)
Most of the work will be the parsing and viewing code for the viewer itself - adding the images/models, won't be much different than adding the dialogue - in fact, might even be easier, since dealing with the GECK won't be necessary.DulogoDigital Utopia (talk) 22:23, January 12, 2015 (UTC)

I don't immediately see any legal issues beyond what we're doing already vis-a-vie images, but I have sent a message to Gstaff @ Bethesda, I will report back if there is a reply. Agent c (talk) 20:20, January 12, 2015 (UTC)

A couple of questions/comments: Users that don't have graphics cards, browsers or operating systems that support WebGL will not see this if clicked, but it won't alter their page view in any way, correct? Two: I believe there are a some typically unused infobox parameters, e.g. image caption, that we may be able to insert a clickable button directly beneath the main infobox image to take them to the 3d model viewer. I'll have to check and see which ones are not used. If this is so, they can be added to the infobox without overriding the main 2D image. The Gunny  UserGunny chevrons 21:07, January 12, 2015 (UTC)
The current test site, already includes cross-browser detection of WebGL support, if you click on the infobox image in a browser that doesn't have WebGL support active, you should just see the normal image viewer instead of the model viewer. For whatever method ends up being used to access the model viewer, similar checks would be used, either disabling, or outright hiding the button.
Currently, the test site uses a slightly modified version of the infobox templates - that do exactly that. If you go and edit the plasma rifle page on that site, you'll see that it has a field named "model" for the infobox. Beyond that, the only other major addition was the javascript to the MediaWiki namespace, that includes the javascript libraries for the WebGL wrapper, and the parser itself, along with - of course, the script that actually ties everything together. My focus was to do as much as possible with what already exists on Nukapedia, without having to make huge changes to layout or templates just to support it. I'll likely have to do more template modifications to handle any additional buttons in the infobox. But those too should be relatively minor.

DulogoDigital Utopia (talk) 22:23, January 12, 2015 (UTC)

How about creating the button as a template itself and we just transpose it into the empty image description parameter of the infoboxes on pages themselves? I'm checking a bunch of pages to see if image description is used at all, but so far that parameter seems to be empty on every page.
Edit: I think if we do this, we should make every attempt not to bury it down in the image gallery. If there's a way to add it to the infobox as a button without replacing the main image, I think that's the way to go. The Gunny  UserGunny chevrons 22:55, January 12, 2015 (UTC)
It's possible, but I didn't want to step over an existing field, just in case - modifying the template really isn't a big deal, just so long as I make sure I do it right :PDulogoDigital Utopia (talk) 23:10, January 12, 2015 (UTC)
One thing I do need to add- I'm pretty confident that most Fallout 3/Fallout: New Vegas, objects, items, and weapons should be supported with the existing code. However, some kind of method for reporting any bugs will be necessary. Perhaps, if it has its own page for instructions/requirements, the talk page could be used to report any display bugs. Editors adding models, and adding them to a page, should probably check first to make sure everything looks good before publishing it.
Creatures, and clothing will come later, as well as animations (idle by default, a drop-down box to choose any additional ones). NPC support will probably come last, as it will require figuring out how facegen works, and how I can apply it to the WebGL wrapper I'm using for the viewer (Three.js).DulogoDigital Utopia (talk) 23:10, January 12, 2015 (UTC)

My concern about the infobox is the size, it would only give a postage stamp sized place for it, whereas in the gallery, the display would be bigger. Agent c (talk) 08:36, January 13, 2015 (UTC)

I'm starting to think that a thumbmail - regardless of location, would be more trouble, and less effective than its worth. I mean, ignoring the extra time it would take to prepare, upload, and edit the page to add it, it would still have a tendency of blending in, and getting lost among the other Gallery images - considering the Gallery's location, and the fact that its purpose isn't immediately apparent to the user. Plus, on top of all that, a thumbnail would have to be added for each variant. However, if it's done similar to this, then not only would its function be readily apparent, but enabling it be as simple as enabling the infobox image (i.e. adding a line to the infobox parameters), and the drop-down could contain any number of the different versions described on the page (i.e. mods, other visually different variants not notable enough for their own page, etc).DulogoDigital Utopia (talk) 13:54, January 13, 2015 (UTC)
See, my main goal with this project (outside of the viewer itself, of course) - is to make it as easy as possible to maintain and contribute to. So anybody that has access to the game files themselves, can convert and make pages for them, and simply edit the infobox params on the related item's page, to make the viewer available. Currently, I'm working on testing out some code that will allow the model viewer to use the native .dds files, without having to first convert them to png. So that everything it uses, will be directly from the game data. When this gets closer to being ready - I'll work on some tools to make the process even easier. Hopefully I can make them work with just Javascript/HTML - so the tools can be actually be on the site itself. DulogoDigital Utopia (talk) 13:54, January 13, 2015 (UTC)

( I like what you've done with placing a "View in 3D" button below the main infobox image, working with a dropdown menu to display more models if they are there. Color is fine for me, and it has a prominent place. It's better than adding a small icon in the top left corner, which tends to overcrowd the 2d model space. I can go along with the naming convention. You will know what will work best. We should keep the image desc parameter, it's used quite a bit. We'll see later on where it should be placed, below or above the 3D button. Good work! Jspoel Speech Jspoel 17:36, January 14, 2015 (UTC)

I looked on a bunch of pages for image description being used. Couldn't find any. Any chance you can link a few that use it? Either way, adding another line to the infobox should not be that big of a deal. The Gunny  UserGunny chevrons 20:24, January 14, 2015 (UTC)
I meant the image description is used in general. You're right you hardly see it on weapon pages. But I would just create a new (or a few new) parameters for the 3D images. Jspoel Speech Jspoel 22:48, January 14, 2015 (UTC)
If we can't have the image on the page itself, then having a view in 3D button below the infobox image seems good. Agent c (talk) 23:10, January 14, 2015 (UTC)
No sense, in my opinion, of reusing existing infobox params for it - considering it's going to require some template tweaking anyway to get that button to show. I'll get it worked out on the test site first.DulogoDigital Utopia (talk) 09:07, January 16, 2015 (UTC)
Quick question: Is it possible for other background colors in the model viewer, and if so, how married are you to the black background? Does a white background make the details of darker model textures stand out more, or does it bleed out lighter colored textures? And thinking completely out of the proverbial (model viewer) box, what about a toggle to change background color? The Gunny  UserGunny chevrons 23:04, February 6, 2015 (UTC)
Sorry I missed this. The black background is certainly not set in stone, it's just the default color - and can be changed to, well - anything really. However, what makes the model stand out, or not - has more to do with the lighting in the scene, than the background - and I'm not completely happy yet with the lighting and the shine. But I was thinking more of a medium/dark grey background, with a Nukapedia watermark. Of course, there's also the option of doing things like the GECK does, and just use a skybox. DulogoDigital Utopia (talk) 00:30, February 10, 2015 (UTC)


Updates[]

This section will provide a log of progress, and other streams of consciousness in the process of getting the viewer and page integration, finalized.

(1/16) - There's a known bug dealing with the display in IE, as well as some issues with getting the window to show up properly; but I'll get to that after the infobox. That being said, I've done a bit of work on the loading process itself. First and foremost, it's now using the actual .dds files (converted to text of course), from the game data. So, now, no conversion will be required, and it should use a bit less memory on top of it. Second, textures are now pre-loaded, with a progress blurb - right after parsing, and before generating the model. At this point, it's back to using the default (3rd person) textures, until I figure out a good way of checking if the high-res ones exist for a particular texture. That's probably going to be the next step, and then I'll start working on the infobox on the test site. DulogoDigital Utopia (talk) 09:07, January 16, 2015 (UTC)
(1/17) - Texture loading change seems to have fixed the display issue in IE. Work on parsing the .esm format has begun, with the goal of creating a dictionary of sorts, to tie model files, texture files, texture replacements/sets, and mod info, to the items FormID/EditorID. Not only will this allow for the display of 1st person (high res) textures without hassle; but it will also do the same for modifications, as well as items that simply use a different texture, for the same model (like Q-35_matter_modulator). DulogoDigital Utopia (talk) 16:11, January 17, 2015 (UTC)
(1/20) - Initial Esm parsing is complete - covering all GECK sub-categories under "Items", Texture Sets and Statics. Testing was successful on all NV and Fo3 ESMs (including DLCs). Not all of these will be supported in the viewer initially (esp Armor/Armor Addons); but I'm thinking ahead a bit. Next steps are to combine everything, and export the necessary information into a format JavaScript can use (i.e. JSON). DulogoDigital Utopia (talk) 19:42, January 20, 2015 (UTC)
(1/21) - Weapon data conversion to JSON is complete, which is the most complex, and can potentially have the largest amount of data attached to it (i.e. mods, first person models, texture replacements for all), for the main New Vegas ESM data. Output is around 300kb. Next up will be the rest of the categories, and then finally, before final output - "merging" the ESM data, adding items by editor id that don't already exist. Order will be FalloutNV -> New Vegas DLCs -> Fallout3 DLCs -> Fallout 3. Since stats aren't really important, this will make sure that only models/textures that aren't already used in the newer game (and thus, potentially better quality/more options), will have to be added from Fallout 3.
Currently, the viewer works like this: nif file is referenced in the infobox, which it then loads and parses, then scans through the resulting data looking for unique textures to load, preloads the texture data, and then converts the nif data for use in the viewer. Once the JSON dictionary is complete - the editor id will be referenced in the infobox, and the option chosen via the button/menu will both be used. Once a choice is made, it will grab the information for the chosen editor id, and load the .nif file based off of any options. When it gets to the point of loading the textures, it will look for any texture replacements, and override the nif-referenced texture with the replacement, and load that instead. A similar process will be done when actually applying the textures as well.
The "View in 3D" button itself, will load the basic model for the given item. When armor is supported, it will load the male variant, and if there is a female variant, there will be a menu. For weapons, the menu itself will contain the basic model, and all mod combinations. Each entry will also have a "First Person" button, to load that version as well. My initial plan of using the 1st person textures on the basic model, had to be scrapped after noticing that a lot of the first person models, differ from the base model - and the first person textures are actually defined in that model's nif instead. Which means, in order to make it standardized, and load firstperson textures by default, I'd have to parse not one, but two nif models before being able to show it. The first of course, being the base model - the second, the 1st person model, just to get the texture names. So, for a matter of compromise, I've decided to just run with the idea of a "first person" button for each entry that has one.DulogoDigital Utopia (talk) 15:48, January 21, 2015 (UTC)
Just wanted to make sure you knew at least some people are reading these and watching your progress. Give us a heads up when you update the systems at the test wiki so we can try them out (and bug check, I guess).  The Gunny  UserGunny chevrons 20:48, January 21, 2015 (UTC)
Thanks for all your updates on the progress! When we can chip in you'll let us know, allright? Jspoel Speech Jspoel 23:10, January 21, 2015 (UTC)
I hope to get the esm data output integrated into the page/viewer by the end of the day, and then comes the page work itself - so within a few days, I should have something close to the final layout/method set up. Main reason I've been giving updates, is to show that work on it is still being done and progress is still being made, even if it's not immediately obvious to someone visiting the test site. When there's actually something visibly done - I'll create a new section here, to let everybody know.
Current plan is, once the page/template stuff is done - I'll start working on a utility that will make adding models/textures a lot easier. I'm going to try my absolute best to make it pure Javascript, so that it can be done completely in the wiki itself; but I can't guarantee anything quite yet. The idea currently, would allow someone to drop a nif or dds file, from the proper path (i.e. Data/textures/... or Data/meshes/...) on the page, and have the page automatically convert the file to base64 (with pre tags), display the output, and provide a link to the page where it should go, based off the file path.
What I'd like to happen, is once everything is set up, that anybody here, can get in some practice with the process of adding model assets, and adding the model property to the infobox for an item/weapon. That way I can get some feedback on ways to streamline the process, and of course, addressing any issues with the display of the model itself. This of course, would be at the test site - any weapon or item page someone wants to try out, can be copied over to the test site. I believe I have most of the templates/add-ons set up, that this site uses. Obviously pictures won't show up in that case, but those aren't really important for the purpose at hand. So yeah, it won't be too long before I'll need as many people as possible to help :p.DulogoDigital Utopia (talk) 16:02, January 22, 2015 (UTC)
(1/23) - Parsing and formatting is essentially finished - still working out some small format issues with the JSON right now. Should be fixed and ready for usage shortly. Once that's done, work will begin on the test page itself - so if you head over there today, don't be surprised if things are broken. Goal for today is to at least get the viewer to work with the data, off of the editorid value for the model parameter of the infobox. Once that appears to be working, I'll be moving ahead with adding the button/menu, and some kind of alert for any missing textures or models - to alleviate any guesswork when it comes to adding things. DulogoDigital Utopia (talk) 21:51, January 23, 2015 (UTC)
(1/24) - A few setbacks ended up turning that "shortly" into an all day affair - however data is finally up. Integration with said data is also complete -including the use of texture replacements, and loading a specific model via an index. The latter will be used in coordination with the button/drop-down. At the time of writing this, the viewer on the test site is essentially off-line, as it will stop at 11% when loading the textures. This is due to still working on a way to create a list of missing textures, without impeding the loading of the model. I will update this, when this issue is resolved. DulogoDigital Utopia (talk) 23:00, January 24, 2015 (UTC)
Alright - model will now completely load, regardless of whether all the textures are present. If they are not, a gray texture is used as a placeholder, and the missing files are added to a list. When any files are missing, an exclamation button appears in the bottom right corner of the viewer. Clicking this will display a box immediately above that button, listing any assets that are missing, and encourages the person to add them. Eventually, it will contain a link to a page with instructions on how to do so. Now that the viewer code is handled, it's time to move on to adding the button/menu. DulogoDigital Utopia (talk) 03:28, January 25, 2015 (UTC)
(1/25) - Infobox template modification is done for the magic button, menu is populated and styled, and both are linked to code, albeit that code doesn't really do anything yet, except print the selected index to the browser's developer console. Further adjustments will likely be necessary with the menu text, to balance readability, appearance and clarity - especially with weapons that have 3 mods. The next step will be re-creating the lightbox, to be able to use it on demand, instead of having to hijack the one wikia creates. A couple of notes about the button. As soon as the modelviewer script loads, it checks for WebGL - if it fails that check, it makes the entire row/button disappear. Otherwise, it will initially be disabled, with the text of "Loading...". Once the data is loaded, the button will be enabled, and the text will change to "View in 3D". DulogoDigital Utopia (talk) 23:28, January 25, 2015 (UTC)
I like the design of the button. Subtle and clear. - Greets Peace'n Hugs (talk) (blog) 23:51, January 25, 2015 (UTC)
Thanks! I'm really trying to keep within the theme as much as possible. I feel it would take away from the benefit of the viewer, if everything else about it looked like crap :p DulogoDigital Utopia (talk) 05:21, January 26, 2015 (UTC)
(1/25 pm) - Viewer is now tied exclusively to the button/menu itself, and everything from the infobox template, to the viewer code, has been divorced from the infobox image. Viewer is also completely functional with the button/menu choices - missing textures and models aside. As mentioned earlier, the viewer now uses its own "lightbox", independent of the wikia system. This eliminates the errors and quirks from the original method of hijacking Wikia's, plus gives me a little bit more flexibility. For instance, instead of picking one size, or nothing at all, the viewer should automatically fill up 80% of your browser's window - regardless of screen resolution. While it won't change the size once it's open, neither does the Wikia one - so /shrug.
Next order of business is the converter tool, and on that subject - I've discovered some good news. HTML 5 has a native file upload API, which means that can be handled entirely within a wiki page! Well, for people with browsers that support it anyway - which should cover the majority of users. So, that's the next step - to work on a nice, user-friendly converter, to expedite the amount of assets available. DulogoDigital Utopia (talk) 05:21, January 26, 2015 (UTC)
(1/27) - There is currently a bare-bones demo of the loader/converter here. Simply drop a nif/dds file in the pretty box, and if everything goes well, you'll see the filename, link to the page it's supposed to go on, and - most importantly, the base64 encoded data, already surrounded by pre tags. Simply copy, go to the page, edit it, paste and publish. As I said though, it's bare-bones, and merely a demo. A better appearance, support for multiple files at once, and better feedback/ease of use features are forthcoming.
The method has deviated a little from my initial plans - mostly due to the fact that, for security reasons, only the filename itself is available when uploading files. So it's impossible to get an idea of where a particular file is supposed to go, just from the upload itself. To compensate for this, I proceeded to extract every Fallout 3 and New Vegas texture and nif file from the game archives, and exported the file name, folder path, and size for each one, and formatted it for use with javascript. So when a file is dropped in the drop zone, it first checks the file extension, then the file name and size are compared to the information in the array - if it finds a match, it generates the proper page name and displays it - before proceeding to upload. Once that's done, it encodes the file data, and spits it out to the text area.
In order to further test the process of adding a new model to a new page, I copied over the 10mm Pistol. Despite having to make a few tweaks to the parsing code, everything else worked perfectly, after only adding the model param to the infobox, with the its editor id as a value. That being said, you can certainly tell that the drop-down needs some better formatting. Currently I'm leaning towards adding a number in parenthesis after the mods i.e. (1), (2), (3), and listing combinations by simply showing something like "Mod 1 & 2", "Mod 1 & 3", "All Mods". That way I'm not trying to cram a ton of text in such a small area. DulogoDigital Utopia (talk) 15:58, January 27, 2015 (UTC)
(1/28) - The AssetLoader is now fully operational, with a new look and a bunch of additional features and/or improvements.
  • A new look that fits in better with the existing theme
  • Support for multiple files at once
  • Significantly faster file matching
  • Descriptive, and color coded status messages
  • A check for, and a warning when an asset already exists
  • The ability to post an uploaded asset, directly from that file's "block"
  • A check for whether or not a user is logged in
  • Response error handling, when posting a new asset - to inform of any permissions issues.
  • A larger drop area.
So, feel free to give it a spin, and let me know what you think! DulogoDigital Utopia (talk) 21:20, January 28, 2015 (UTC)
Asset loader works great, couldn't be better. I do have a question though. Maybe I'm missing something, but there are many editor ids, nif files and textures files that have the same name in Fallout 3 compared to New Vegas. Probably plenty are the same and can be used for both, but I can imagine there also with the same name, but with different contents. How do you solve that? Jspoel Speech Jspoel 23:24, January 28, 2015 (UTC)
These 3D models are looking fantastic guys! Check this out for an example! (click on the eye icon in the 3D button). Jspoel Speech Jspoel 23:51, January 28, 2015 (UTC)
As far as I've seen - Bethesda/Obsidian has been pretty good with their editor IDs between games. If the same editorID exists between games, it's the same item (i.e. see Plasma Rifle). If there's a New Vegas version that would use the same name, Obsidian generally puts an 'NV' in the ID name. Obviously, if exceptions to the rule show up, they could be handled in some way. That being said, considering the Plasma Rifle, I'm going to leave a note for myself for the script to check which game the page belongs to. It might speed the initial loading up a bit, plus - showing mod choices on the Fallout 3 page would be kinda counterintuitive. DulogoDigital Utopia (talk) 01:46, January 29, 2015 (UTC)
(1/29) - Game detection is done. It will now only load the data for the game the item page is for. This results in about 50% reduction in the delay between page load, and the availability of the button. For weapons that are in both games, this means that they'll use that game's information. Meaning, no mod options on the Fallout 3 version. Texture loading is now "stepped" to reduce the chance of annoying "unresponsive script" warnings, and a general smoother response. This is done similar to the parsing and model generation, by basically waiting 5ms between loading each texture. Finally, I tracked down, and fixed a bug that was resulting in the both the replaced textures and the originals being loaded, so that cuts down on load times as well. DulogoDigital Utopia (talk) 08:19, January 29, 2015 (UTC)
Also just put in a request for the namespace "ModelData" on the test site. As soon as it's available, I'll be re-adjusting the asset/viewer code to work with the new namespace. DulogoDigital Utopia (talk) 08:36, January 29, 2015 (UTC)
(1/30) - Added parsing support for the necessary node types for armor models. However, the necessary code to actually display these objects is still forthcoming. All this means, is the parsing portion of the loading will reach 100% without error; but after a brief "Generating Model" phase, you'll be left with only a blank view. Hopefully tomorrow there will be something to actually see. DulogoDigital Utopia (talk) 08:26, January 30, 2015 (UTC)
Also fixed a bug in the AssetLoader that could cause it to hang when adding a mesh or texture that appeared in both games, but had different sizes. DulogoDigital Utopia (talk) 09:17, January 30, 2015 (UTC)
That's what I refered to earlier. Weapons having the same name, but with different mesh/texture sizes. For example the Fallout 3 hunting rifle mesh is a different one than the New Vegas hunting rifle mesh. So two meshes need to be created, but there's a problem with the name as both want to use meshes-weapons-huntingrifle.nif. Same for the texture files. Jspoel Speech Jspoel 15:55, January 30, 2015 (UTC)
Sorry, I thought you were talking about the editorID. But in that case - I looked at both models/textures, and yeah...ordinarily I'd say just go with the NV version first, because they look the same (NV textures are just better quality); but I just noticed that the NV rifle has different node names. Alright, then. I'll figure something out. DulogoDigital Utopia (talk) 07:06, January 31, 2015 (UTC)
(1/31)- A bunch of odds and ends
  • Asset Loader now loads one file at a time, to better handle a large number of files at once. Previously - attempting to add more than 4-5, would result in...forgetting it had files to go through.
  • Encoding has been tweaked slightly, to only use characters outside of the standard lower/upper case letters. This was done in response to Wikia's spam filter blocking one of the models, because the encoding spelled out p*rn.
  • The text box section from the file boxes in the AssetLoader have been removed, as the only purpose they served was to eat up more memory.
  • The AssetLoader will now auto-post, if it discovers there isn't a page yet for that asset. If there is a page, it will give you the option to post, or to skip.
  • The AssetLoader now stores game assets, per game. All Fallout 3 files will be prefixed with "F3-" and New Vegas, "Nv-". This is to avoid conflicts that Jspoel pointed out.
  • The AssetLoader will now collect all matches, where the name and file size are the same, and post them as well. This means if a particular asset is shared between games, and/or appears in more than one location in a game, it will post to those locations as well.
  • Files that are larger than 1MB (1024kb) will be split over two pages. Previously, larger images wouldn't be able to be posted, despite the fact that they're still under the 2048kb limit for page text. Now, when an image is larger than 1024k, the remainder will be split, and posted to a page with the same name, only with a "p2" tacked on to the end of the title.
  • Model viewer has obviously been updated to handle the above changes.
Provided that no other issues pop up, the two things on the agenda for tomorrow is a progress bar for the AssetLoader, again - mostly for bulk file adding, with status colors to alert the uploader if one of the boxes needs your attention. After that, comes working on generating the parsed data from armor. DulogoDigital Utopia (talk) 12:08, January 31, 2015 (UTC)
You had a real busy day yesterday! Solving the problem between the files of the two games, splitting files, finding a way to circumvent the spam filter and updating the asset loader in that time is impressive. Good to see this progress! Jspoel Speech Jspoel 16:14, January 31, 2015 (UTC)
Not exactly my favorite use of time; but it defeats the purpose if it can't be dependable :p. That being said, I can't find any way to protect a namespace, or prevent it from plastering itself all over the recent changes. The former I know I could just throw together a script to run through all the pages in the namespace, and protect each one; but the latter seems to be globally user-based.DulogoDigital Utopia (talk) 03:13, February 1, 2015 (UTC)
(1/31pm)- The AssetLoader now has a progress bar, that reflects the status of the current file. Bar/text updates per asset, and per post (see possible reasons for multiple posts per asset in the previous update). Text label will show any messages, as well as a <finished> of <total> (<percentage>) info. Percentage and bar width will update with each post, as well as each asset, while the finished count, goes by asset alone. I also added a background color change in the drop zone, to provide visual feedback for dropping files. Possible bugs notwithstanding, that pretty much wraps things up for that system. Now it's time to dig in the model viewer again, and see if I can't get armor/clothing to display. Just a warning, that the viewer may be periodically broken while in the process of working on it. I won't really be touching the code that generates the other stuff; but mistakes happen. DulogoDigital Utopia (talk) 03:13, February 1, 2015 (UTC)
(2/1am)- Fixed an issue with the file splitting - a single character was getting repeated across the split, leading to texture display issues. Files will need to be uploaded...again. And also, this
Viewer has gotten a new control system, as the original one didn't work well with the size of the armor models. Models will also now be centered, and framed within the viewer on load. DulogoDigital Utopia (talk) 16:14, February 1, 2015 (UTC)
The armored vault jumpsuit gives a loading progress, but I don't see the model yet, only a black screen. Jspoel Speech Jspoel 17:17, February 1, 2015 (UTC)
Try doing a hard refresh, by either doing ctrl+f5, or holding down the shift key before hitting the reload button. It's very likely that the old version of the script is still cached. DulogoDigital Utopia (talk) 18:02, February 1, 2015 (UTC)
Ah ok, that worked. Another thing I noticed is that the weapons aren't displayed from the side anymore after loading, but viewed from topside. Can it be changed back? Jspoel Speech Jspoel 18:11, February 1, 2015 (UTC)
I'll find a good way to handle things differently by type - because, currently if I rotate weapons so they're being shown from the side, then characters/armor would show up with the camera pointed at the bottom of their feet. Basically the same reason why Nifskope shows weapons similarly. But it shouldn't be a problem to handle things differently per type. Just a warning, both the AssetLoader and the Viewer will be in various stages of working order today. Not just for the display adjustment; but also better handling for split files. It seems, in some cases - two parts aren't going to be enough DulogoDigital Utopia (talk) 18:57, February 1, 2015 (UTC)
(2/2am)- Weapon models are now rotated differently than others, so they're back to the orientation they were originally. Initial zoom was tweaked so that a model "fits" better within the window. Next steps to follow, later today. DulogoDigital Utopia (talk) 08:49, February 2, 2015 (UTC)
Okay - I'm not happy at all with my current method for separating the alpha channel from the normal map textures. The performance hit is far too large, especially on 1st person models. So to address this, I'll be working on a shader that should be able to this through the GPU's graphics pipeline - essentially modifying the gloss level applied per pixel, based off of the information in that normal map texture's alpha channel, in process. The nice thing is - once I figure that out, is that the same technique can be used to support the other types of textures as well. DulogoDigital Utopia (talk) 16:20, February 2, 2015 (UTC)
(2/3)- Work continues on the special shaders/material - shifted work back to a local setup to speed up turn-around, so no chance of the viewer on the test site getting broken. Setup is complete, with a custom renderer/material, with the two additional texture types defined (glow map, and environment mask). In addition, I finally figured out how to get the environment texture to work properly. Once the environment mask texture shader is working, that glassy effect should be limited to the actual...well, glass. Work on the shaders themselves will begin later today - which will include getting the gloss map from the normal map texture's alpha, the glow map, and the environment mask. DulogoDigital Utopia (talk) 12:47, February 3, 2015 (UTC)
This is all a bit technical but it sounds good. I'm already pleased with the results so far. Armor and weapons are displaying nicely and the Assetloader is really a great tool. I would say it won't be even that hard to add all these nif and texture files on our wiki once the programming is streamlined, you can select all files in a map, drop it in the tool and everything is done for you. Jspoel Speech Jspoel 21:17, February 3, 2015 (UTC)
That's certainly the goal - namely to make it so it's just as easy as adding a photo. Arguably, it might even be easier than that right now. :p That being said, a lookup utility probably would help a great deal. Something where you can search for the actual name, and it will display the editor id, as well as the required model (and if the model exists, any required textures). That way it wouldn't even be necessary to use the GECK. I'll look into it once I get the viewer updated. DulogoDigital Utopia (talk) 21:24, February 4, 2015 (UTC)
(2/5)- Glow and Shine textures now supported on the viewer on my computer - reflection may also be, but I need to test it out on a few more scoped weapons. Over the next day or two I'll be looking over a variety of models to make sure I have the textures doing what they should be doing, and then probably push the changes live towards the end of the weekend. DulogoDigital Utopia (talk) 09:52, February 5, 2015 (UTC)
(2/5pm)- New version of the model viewer is now live! Changes as follows:
  • Specular map (shininess) now works correctly
  • Specular map is now read from the alpha channel of the Normal map, in the process of rendering - no need to split the channels means significantly faster texture loading times, and less CPU load - with no drawback in view performance.
  • Glow maps are now supported! This means all the glowy bits will appear correctly (i.e. crosshairs on the laser rifle scope).
  • Environment Maps and Masks are now supported! This means the reflecting parts of scopes and the like, will appear correctly.
  • Viewer code has been updated to load all appropriate textures.
  • Another previously unsupported nif structure was added to prevent parsing bugs in some models. This type of thing will likely continue until all structures are discovered, as parsing bugs appear.
So, feel free to check it out! DulogoDigital Utopia (talk) 02:00, February 6, 2015 (UTC)
(2/6)- Work has begun on an asset lookup utility. Primary purpose will be to provide an easy method of getting the Editor ID of a particular item, by typing in that item's name. It will support auto-complete, showing the first 5 results, with the related game's icon next to each result. Other possible features, include an asset report, showing exactly which models and/or textures the item uses, and possibly even a check to see which assets exist. DulogoDigital Utopia (talk) 12:36, February 6, 2015 (UTC)
I was wondering about the models for Fallout 3 and Fallout: New Vegas. When I upload a Fallout 3 nif or texture file (F3...) it automatically adds an Nv named version. But the Nv version uses the F3 model, right? So that would be wrong. Then when I try to correct that and upload the Nv version, it adds an F3 named version as well, but overwriting it with the Nv content. So then you have a problem there again. Another thing, I just experimented with the 1stpersonhunting rifle, but I have problems uploading/overwriting articles; the texture file didn't want to upload. Do you know why? And how's the work on the DLCs progressing? I'm trying the Winterized t-51b power armor, but the progress is halted at 5% parsing format. Jspoel Speech Jspoel 16:41, February 6, 2015 (UTC)
This is what it does - when it gets a file, it searches the data for both games, for any matches with exactly the same filename and the exact same size (in bytes), and uploads for each match. So, in effect, the files themselves should be the same. If you run into any situation where two files are indeed different, but have the same name and size, please let me know - and I'll find a better solution. The texture upload issue for the 1stperson texture was due to me deleting the page - I'll look into the exact reason why this causes it to fail - but it's likely due to the status code (i.e. like a 404 error - but in this case it's 410). Upon uploading that texture, I also noticed a display issue with the sights, where they appear as completely black. I'll get to the bottom of that issue, as well as, the parsing error on the T-51. The latter isn't related to the DLCs - as the winterized T-51 is just a reskin of the standard one (i.e. same model, different textures). DulogoDigital Utopia (talk) 19:09, February 6, 2015 (UTC)
  • Models with texture coordinates outside the standard range, will now display correctly. (most notably, parts of the Hunting Rifle)
  • Fixed one Nif structure, and added a missing one. T-51 Power Armor (all variants) should now parse correctly.
That should cover things for now, let me know if you run into any more bugs! DulogoDigital Utopia (talk) 21:28, February 6, 2015 (UTC)
The neck of the female armored Vault 13 jumpsuit is still visible and looks like a bug to me. Pretty gruesome sight, best to get rid of that.It's not there anymore. You probably just fixed it already I suppose. Jspoel Speech Jspoel 23:07, February 6, 2015 (UTC)
Yep! Before I was looking for specific part names, but then I noticed that the T-51 just used a generic name for its gore parts. So I just changed the code to look for any part that uses that specific texture. DulogoDigital Utopia (talk) 23:53, February 6, 2015 (UTC)
(2/6pm)- The Asset Lookup tool has basic functionality. Type in an item's name, and while typing it will present you with matches from the data I gathered from the esm files. Each result will have the form/baseID in parentheses, and an icon indicating which game the item belongs to. Clicking a result will add a section showing the exact text to add to the infobox for that item's page, including the editor ID. More information will be added, as progress continues. I'd like to turn the result into a report of sorts, listing all models/textures used by the item, and showing the availability of these files on the wiki. DulogoDigital Utopia (talk) 04:45, February 7, 2015 (UTC)
Can you give an example of a working search term? I haven't been able to get an item to appear in the search bar. Jspoel Speech Jspoel 14:08, February 7, 2015 (UTC)
I'm trying to add the texture files of the Anchorage version of General Chase's uniform, selecting the outfitm in the ArmyGeneral textures map. Instead it nows starts adding outfitm textures from every Fallout 3 map (64 files). That's not supposed to happen I would say. Jspoel Speech Jspoel 15:32, February 7, 2015 (UTC)
It will only start showing results after 3 or more letters are entered, and you might have to wait an extra second or two - the loading thing is currently clearing a bit too soon. As far as the files go, I guess that's enough evidence for a reason to implement a better check. DulogoDigital Utopia (talk) 16:37, February 7, 2015 (UTC)
(2/8)- A few significant changes to the AssetLoader
  • file path data, now includes an md5 checksum of the file, in addition to path, name, and size.
  • AssetLoader will now generate a checksum of the uploaded file(s), and, in addition to file name, and size, will use it to identify the file. This is the same type of hash that is commonly used to detect whether a file has been corrupted during a download, in this case it works beautifully for matching. For example, checking the entire 2handrifle texture folder from Fallout 3, returned zero NV matches. Checking General Chase's overcoat texture (outfitm.dds), returned two matches. Both from Fallout 3, with the first being from anchorage, and the second from zeta.
  • Because the file data was necessary before checking for a match, the process had to be switched around a bit. AssetLoader will now load every file given to it immediately, and file data will be stored, before going through each file sequentially to match, check for page, and post. The added benefit of this method, is that it effectively removes any limit on the number of files you can upload at once. However, keep in mind that this means that the data for every file you upload will be stored in your computer's memory, and textures especially start adding up. So I wouldn't try uploading the entire contents of your Fallout 3 folders at once - your computer might hate you forever. :p
  • A few changes were made to increase overall performance, especially when checking files, as well as initial load. Unfortunately there's little that can be done about the posting time.
DulogoDigital Utopia (talk) 13:03, February 8, 2015 (UTC)
You're making it more and more convenient for us! Yesterday the asset lookup didn't work for me, but now it does. Easy to use and to paste in the infobox. I do have a problem with a few Lonesome Road armors, they won't load. May be a bug? Jspoel Speech Jspoel 00:36, February 9, 2015 (UTC)
Just a slight oversight - I moved the parser code itself to its own file, and made the adjustment for single-page meshes, but forgot to do the same for multi-page ones (i.e. nifp2..etc). That being said, something weird is going on with the arms on that Scorched Power Armor. NifSkope shows the same thing, but the GECK does not. I'll look into getting to the bottom of it. DulogoDigital Utopia (talk) 04:55, February 9, 2015 (UTC)
Seems to be automatically fixed by applying the model's animation rigging (i.e. bones). I'll work on implementing handling for that. Like the shaders, this will need to be worked on, on my computer first, instead of the test site. So no worries about that being offline for the next couple of days. Just a reminder, you will have to probably do a Ctrl+F5/Shift+F5 reload so your browser will load the updated viewer code, with the fix for the multi-page models. DulogoDigital Utopia (talk) 05:11, February 9, 2015 (UTC)
(2/9)- Work has begun on planning out the implementation of the bones/rigging of the armor models, to address some display issues, where the model parts themselves, aren't positioned where they should be, per the part data itself. Unfortunately this is going to probably take a few days, as I have to reorganize how the model is generated. DulogoDigital Utopia (talk) 01:05, February 10, 2015 (UTC)

Bethesda Response[]

Response from Gstaff is they think it's a "cool idea". He's also mentioned some have used "sketchfab.com" for similar effects. Agent c (talk) 11:36, January 16, 2015 (UTC)

Glad to hear that we have their support! DulogoDigital Utopia (talk) 17:54, January 16, 2015 (UTC)
Awesome. JASPER//"Do you like hurting other people?"UserRichard 23:23, January 21, 2015 (UTC)

Phase 2[]

Well, This is probably not the best name for it, but it'll do. Since I took a "break", I figured the page should get one too. Not really a break, just busy with other stuff, and admittedly a little burned out. However, as the saying goes - absence makes the heart grow fonder, and of course, the Fallout 4 hype certainly didn't hurt. :p

Going forward, I've got two personal goals with this project. The first is support for loading multiple .NIF files - to not only cover various armor parts (gloves,etc.), but also to make use of the basic male/female models, so we don't have to look at creepy decapitated models for armor. In addition, the infobox will allow for more than one editor id, to make it possible to show complete sets, the way they're currently shown on the page. (i.e. helmets).

The second goal, will be the support for creatures. Basically any non-human/ghoul character in the game. These will also generally require the aforementioned multiple .Nif file support.

One final thing I'm likely going to do, is add idle animations, so these models aren't stuck in their "T-Pose". Further animations, at least in my opinion, don't seem to hold much value.

Human/Ghoul NPCs are mostly dependent on Facegen, which is, for all intents and purposes an unknown to me at this point. Something I'd still like to do at some point; but at least as long as I've got more pressing things to figure out, it can take a back burner.

Anyway, it's time to get the update log going again. So, without further ado, I'll continue.

(6/13) - Bones/Rigging has been implemented to Armor - nothing really outwardly different here, with the exception of it fixing the Scorched Sierra Power Armor bug with the arms.
(6/15) - The application I'm writing for extracting data from the ESM files, to export for use with the 3D project, will now include data for display flags (i.e. to tell what parts of the character model to hide), as well as armor pieces (or ArmorAddons in the GECK).DulogoDigital Utopia (talk) 10:31, June 15, 2015 (UTC)
(6/18) - ESM Parser tool can now parse creatures, and output relevant data. Rough templates for NPCs, Eyes, hair, facial hair, and race types have been added, for future parsing of that data. Work begins on modifying the local copy of the viewer, to support loading and display of multiple .nif files in a single scene. DulogoDigital Utopia (talk) 08:46, June 18, 2015 (UTC)
(6/19) - Model Viewer on local server now has support for multiple objects/models. Next up, support for creatures, before porting over to wiki.DulogoDigital Utopia (talk) 09:50, June 19, 2015 (UTC)
Mv prev6-19

Local server preview of Model Viewer, showing loading of two objects, containing 5 different models.

(6/22) - To facilitate more streamlined,unified development, I've created a stand-alone copy of one of the test site pages, on my local server. What this means, is that both the test site, and my local...test site, share the same exact code. DulogoDigital Utopia (talk) 07:17, June 22, 2015 (UTC)
(6/24) - Code cleanup/reorganization is nearing completion, and with it, the final features I want to add before I feel it's ready to go live, here. Once this cleanup is completed locally, I'll sync it with the test site, and verify the file loading is working there. So, don't be surprised if the viewer on the test site isn't working in a day or two - as it's possible the loading might be temporarily bugged. I'll at least make another update here, once it's ready for another closeup.DulogoDigital Utopia (talk) 03:59, June 25, 2015 (UTC)
(6/26) - Code rewrite done, still some tweaking left to do before putting it up on the test site. In the meantime, here's a few new shots showing the extra features it'll support. DulogoDigital Utopia (talk) 09:50, June 26, 2015 (UTC)
(6/27) - New build of the model viewer is up and running on the test site. New features include:
  • Creature support, with support for multiple,comma separated Editor IDs in the template, to allow choosing from variants (e.g. Deathclaw_(Fallout:_New_Vegas))
  • Creatures now support multiple NIF files per Editor ID (e.g. Primm Slim)
  • Armor now supports a second (comma separated) Editor ID in the template, for armor that has a helmet. (e.g. Enclave Officer Uniform)
  • Armor now supports multiple NIF files per Editor ID (i.e. gloves, etc.), and will also load default Male/female body parts if applicable. Hair color still needs to be fixed. (see above for example). Edit: hair color is a bit more natural now. :p
  • Viewer code has been reorganized to increase flexibility and remove "garbage" code that still remained from earlier development
  • Local code and "live" code are still one in the same, with a "switch" used by the loading methods, between the page-stored files, and local files.
DulogoDigital Utopia (talk) 02:16, June 28, 2015 (UTC)
(7/1) - One of those good news/bad news kinda days. Good news is, upgrading the webgl wrapper (three.js), provided the ability to modify the render order on a per-mesh basis, so the hair bug is fixed (local build). Bad news is, the upgrade broke my custom shader, so I'm going to have to fix that before I update it on the test site. DulogoDigital Utopia (talk) 21:01, July 1, 2015 (UTC)

Moar Comments/Feedback Here[]

i tell ya what, this is some on the cleanest shit i've ever seen on a wiki, when can we have this on here??? Detroit lions Hawk da Barber 2013 - BSHU Graduate 23:26, June 22, 2015 (UTC)

To be honest, with all the hacks and kludges I've had to do, I'm even amazed that it works at all, let alone, works well. :p Unforeseen issues not withstanding, it should be ready in a week, two tops. Currently working on cleaning up the code, to make it a bit easier to add in the last few bits for full armor/creature support. DulogoDigital Utopia (talk) 02:13, June 23, 2015 (UTC)
Looks great and am looking forward to seeing it here! Still some bugs, if you click a variant deathclaw in the infobox, you get red gibberish. And some glitches with the hair in the Enclave uniform. Jspoel Speech Jspoel 15:15, June 28, 2015 (UTC)
All Deathclaws seem to be loading fine on my end, which variant gave red gibberish? DulogoDigital Utopia (talk) 21:58, June 28, 2015 (UTC)
They're all fine for me, too. JASPER//"Do you like hurting other people?"UserRichard 22:01, June 28, 2015 (UTC)

( Here's what happens when I click on the deathclaw baby variant link in the infobox. Not the 3D button, but the link below it. Jspoel Speech Jspoel 22:09, June 28, 2015 (UTC)

Deathclaw test site bug
Not a result of clicking on the Deathclaw baby in the infobox, but rather of just scrolling down the page. The test site does not have all our images and templates on it, so those are just a bunch of red links. JASPER//"Do you like hurting other people?"UserRichard 22:20, June 28, 2015 (UTC)
Oh, I see. Yeah, that's just because I didn't copy over those images, so the alt-text is shown instead. In this case, said alt-text is significantly larger than the space that the icons take up, which causes it to do...well, that. :p DulogoDigital Utopia (talk) 14:48, June 29, 2015 (UTC)
Advertisement