ndix UR

When you say you 'turned off' the bumpmaps, do you mean removing the TXI information, or also turning tangentspace to 0? I just spent a bunch of hours debugging a crashy area level that was due to having tangentspace 1 on meshes that did not have normal mapped (or envmapped) textures. Dunno if that is an issue here, but it's probably worth making sure you disable tangentspace calculations during the ascii->binary compile when you are testing mesh alpha to get clean test results. I've only seen the issue on an nvidia device and, since it's a vanilla area model, it's not an issue with our compiler tools.

If you have a little bit of extra disk space, you should definitely record to a lossless format like WAV (w/ a lossless compression) or FLAC, then export your files from Audacity as MP3 once you are done with your editing. Because MP3 Is a lossy format, each time you save out a file you are slightly reducing the quality of your files. The bitrate/quality level and whatnot you'd normally use in-game is pretty low, so it might not be a big deal either way, but working in lossless and exporting to lossy is just a general best practice. Also, when you're making your volume adjustments, try not to let your audio 'clip'. Details on how to achieve that in Audacity can be found in their manual wiki on the Amplify & Normalize page. Audacity can also use VST plugins, of which there are quite a few good free ones nowadays (and some amazing ones if you want to pay). Certain VST plugins will help you change the *apparent* loudness of files without having to just crank the knobs, causing clipping in other parts.

Yes, this is a primary motivation for the project.

My suspicion is that there is some bad geometry or loose vertices or something somewhere in the model. If you use MDLedit's 'Minimize (weld) vertices (Ascii)' function, the crashing goes away. Personally, I recommend always using that setting unless it is messing something up for you (or you are doing very specific model comparisons etc.). First hint was that a mdlops compile 'just worked' (it doesn't separate out minimize/addition of vertices like mdledit does. in mdlops the option is just 'validate' yes or no, validation being minimization as possible and addition as needed. mdledit does addition as needed always, but lets you turn on/off the minimization as possible part) There's a chance that number of vertices or something is an issue, but I doubt that. For me, it is much more likely that some bad geometry that could be collapsed confused MDLEdit into putting some bad calculations onto a vert somewhere. I also noticed though that you have the classification of the model set to 'flyer' ... setting it to 'character' would help rule out another issue.

Why not set the alpha on the meshes and make the ghost version a unique model? You have to have the nodes in the right order for it to look right, but ... then it looks right. DP is the expert on the node ordering rules, I always forget the details on that. Using the mesh alpha instead of trying to do texture tricks lets you keep the shiny texture-alpha based settings also... Might be interesting to see what that looked like combined with the shield effect also...

My comment on this is that it still reads very "technically". The important things to communicate in this case, I think, are, "You must use the supermodel from the game version you are targeting." (maybe instead of ", so it could not be used!") and "Animations will be broken on your new model!" instead of "The supernode numbers will be wrong". Because while you and I understand that statement in agonizing detail, it is (and hopefully should be) pretty meaningless to the average modeler.

Excited to try this, it looks great. I noticed a couple things that you may (or not) want to fix while looking at the files. The TXI files contain 'envmaptexture cm_baremetal', but the TGA images do not contain any alpha channel. As I understand it, the envmaptexture should not have any effect in that case? Not sure if the issue is envmaptexture being extraneous or the alpha channel being missing... Also the TXI files for dro_tk04 and dro_tk02 contain numx 12, but I only count 11 frames (like 01 and 03, which contain numx 11). The dro_tk02.txi file contains fps 2 while the others are all fps 1, but that may be intentional, just pointing it out 'just in case.'

File Name: Want Kaah Gone: The Commemorative TexturePack File Submitter: ndix UR File Submitted: 30 Apr 2018 File Category: Skins TSLRCM Compatible: Yes Want Kaah Gone: The Commemorative TexturePack by ndix UR Commemorate the release of the M4-78 "Want Kaah Gone" music video... with this handsome, albeit entirely frivolous, custom texturepack. You too can experience the amazing textures used in this wonderful new offering. Proudly display your ardent desire for Kaah to no longer be present with a set of "Want Kaah Gone" datascreen textures to call your very own. What? You can find the music video here: What? This silly little mod replaces the data screen textures for the M4-78 archon chambers for IS-24, ES-05, and M4-78. Special thanks to Sith Holocron, as the entire project, and these textures, were his idea. Click here to download this file

I can't figure out why they would be different. I did notice that m26aa_set & m26ab_set both use selfillumcolor 1 1 1, which brings with it a bloom effect for users with video buffer effects. I don't know how common a practice that is game-wide, having only dabbled in skyboxes personally. The only other model difference I saw was the addition of AuroraLight02 in m26ab_set. The light is set up as a shadow casting, non-flare light, (slight blue color, much higher multiplier) located closer to the main fountain area in m26ab_set. Another thing you might try is wiping the lens flare lists completely. So, set lensflares 0 (instead of 1), and remove texturenames, flarepositions, flaresizes, and flarecolorshifts from the auroralight01 node. I have a really terrible rig for lighting tests or I would try these things myself, sorry I can't be more help.

Permission for ebon hawk fixes given (again. to anyone. for any purpose within legal limits of their jurisdictions).

I agree about the potential benefit of replacing the Coruscant loading screens (there are 3). They were out of place enough in a modern install that I made (fairly poor) replacements myself (for personal use). One is the EP3 Coruscant cityscape, the other is a Jedi Temple external shot against the Coruscant skybox it used, and the third was an interior hall of fountains shot. Not sure how far down the rabbit hole you want to go, but Azgath N'Dul's Tomb also contains two load screens, load_712KOR and load_713KOR. I *think* they were in-game locales, but it's been awhile.

We're not really planning to write manuals. We leave that for more experienced modelers who actually use the tools. We know how the tools work, which is a whole different thing from how to use them to achieve specific results. I would think revising old tutorials wouldn't be that hard. It should mostly be simplifying the existing instructions, reducing a bunch of workaround steps. I'm not really that great at writing simple instructions, better at convoluted technical details. Also I don't have/use some of the key tools that people consider standard (3DS/Gmax), so it definitely won't be me writing the stuff up. Probably a bigger issue is that the people with access to rewrite tutorials are gone, or the sites they were published on are gone. I know I used a lot of tutorials from LF via archive.org when I was learning. I've written some docs on our extensions to the ASCII format, but that's not really related to user experience. That would be aimed at model tool authors. Regarding supermodels, the supermodel is required to calculate the node numbers. It is a feature of how the game structures models in a hierarchy in the first place. The node numbers are what tell the game engine that MaskHook in your model is the same MaskHook in s_male01, for example, and the supermodels contain most of the animations. The old MDLOps copied node numbers from 'the original model,' because it didn't know how to construct them properly from a supermodel. Those same node numbers exist in the supermodel usually, which is why the 'rename supermodel as original model' hack worked. It wasn't a known or intended use case by the original authors. Old mdlops also copied over some useless run-time data for skin nodes. That part would fail when you used the 'rename supermodel to original' hack, but it didn't matter at all. MDLEdit & mdlops v1+ calculate node numbers properly from the supermodel, but it is simply not possible to do without reading the supermodel. There are a couple interesting ramifications of this change. The node number calculation requires matching hierarchy, so, using 'calculate from supermodel', you can't change the parent of MaskHook and have it still connect to supermodel animations. Using 'copy from original model', you would get away with that. Using 'calculate from supermodel', you are free to add any nodes from your supermodel, even ones that did not exist previously in the model. Using 'copy from original model', you can only do that by doing what DP describes, having the supermodel impersonate the original. All of these technical issues have subtleties I am abusing with this general view, but I'm just trying to clear things up a little bit. Also "MaskHook" is probably not a great node to use as an example but it just popped into my head. It's worth noting that mdlops v1+, like MDLEdit, will use a supermodel (without rename-as-original hack) if you have it in the folder with the model you are compiling. If you don't, unlike MDLEdit, it will fall back to using the old, crappier 'copy from original' method. That is what this is about in the readme: " 5: For importing models that have supermodels, the super model or the original model must be in the same directory as model being imported. Super model is better. " The philosophy of the newer mdlops is to not break the practices people used before, precisely because I didn't expect tutorials to be updated over night (if ever). It's probably not 100% successful in that, but that was a goal.

Is that bug still unfixed in the MDLEdit test build bead-v posted to the bugs thread? I believe that particular fix did make it into MDLOps v1.0.0. It corresponds to the following entry in changelog.txt: commit fa9814ce6629f295d10e4e41791a8f7f266e29ff Date: Mon Oct 16 17:04:24 2017 -0700 Added resolved node order for models where name array is out of order but contain skin nodes because skin node indices refer to node order and not name order As long as he doesn't hit any compressed quaternion related issues, v1.0.0 should work. (If you do, just change compress_quaternions from 1 to 0 in the ascii model file before you compile)