DarthParametric

Modders
  • Content Count

    4,729
  • Joined

  • Last visited

  • Days Won

    538

Everything posted by DarthParametric

  1. First you will need to find the model for the central lounge section of the Ebon Hawk. In this instance I already know it is M12AA_01F. You need to extract the binary model, the MDL/MDX pair, somewhere. Don't convert it to ASCII. Run MDLOps, hit "Select file" and browse to the MDL, set the type to Kotor 1, hit the "Read model" button, then when the output window shows that is complete, hit the "View data" button: You will be presented with a multi panel window (you probably want to maximise it so you can see what you are doing) that shows the model structure on the left, the hex data in the center, and the actual values in decimal on the right. Expand the "nodes" sub-section on the left to see all the individual child objects: We already established previously by looking at the model in Max that the meshes we are interested in are named Mesh27, Mesh30, Mesh117, Mesh118, and Object181, so find those in the list: Now if you expand one of those, let's start with first in the list Mesh118, and click on "subhead", you'll see some data populate the center and righthand panels. Scroll down to the bottom of the righthand panel. I know from past experience that the value for an enabled render flag is 256, which we can see towards the bottom there. For more info on the structure of a model, check out Chuck Chargin's model data table. Now this particular instance is easy, because that is the only value of 256 present. However, the shadow flag also has a value of 256 when enabled, but in this case shadows are disabled, so we don't have to worry about that. But for the record, the render flag should be after the shadow flag. With the target value identified, we need to find the hex value for it so that we can change the value. If you look on the righthand panel, you can see there are five values that follow the render flag value: 0, 0.0199781320989132, 0, 848320, 701705. If we look at the last 4 bytes of data, we see that is 09 B5 0A 00. If we convert that to an integer, we get 162859520, which obviously doesn't correspond to anything. However, KOTOR models are in little endian byte order. Basically what that means is for a 4 byte chunk ABCD, the data is actually stored backwards as DCBA. That means in this case we reverse our chunk to 00 0A B5 09. If you convert this to an integer you get 701705, which is the last value listed in the righthand panel. We can continue working backwards in this manner. 848320 is the 4 bytes C0 F1 0C 00 (00 0C F1 C0), 0 is 4 bytes 00 00 00 00. When we get to 0.0199781320989132, we need to deal with a float rather than an integer, so need a different converter (here's one). This is the 4 bytes 2E A9 A3 3C (3C A3 A9 2E). Now we have the 4 bytes 00 01 00 00, which we know from the righthand panel must comprise two values, our render flag 256 and 0. A conversion tells us 256 in hex is 01 00, which if we reverse is 00 01. So we know the first 2 bytes of that 00 01 00 00 chunk is our render flag. Now we can't just search for a 2 byte chunk 00 01 in a hex editor, there are over 2,700 instances of that in this file. We need that unqiue instance, so we include the surrounding bytes. If we search for the string 00 01 00 00 2E A9 A3 3C 00 00 00 00 C0 F1 0C 00 09 B5 0A 00 then we find a single instance. If we compare the preceeding bytes, we can see they also match what we see in the MDLOps data viewer. Knowing that, we can do a search and replace. We replace 00 01 00 00 2E A9 A3 3C 00 00 00 00 C0 F1 0C 00 09 B5 0A 00 with 00 00 00 00 2E A9 A3 3C 00 00 00 00 C0 F1 0C 00 09 B5 0A 00 which will change the render flag from 00 01 to 00 00, thus setting it to off. Now you just need to do that for all four remaining meshes. To save you some time, here are the search and replace strings you need: Mesh117: 00 01 E6 3D 6A 08 AF 3C 00 00 00 00 80 FD 0C 00 AB C1 0A 00 00 00 E6 3D 6A 08 AF 3C 00 00 00 00 80 FD 0C 00 AB C1 0A 00 Object181: 00 01 00 00 43 F3 2B 3C 00 00 00 00 60 10 0D 00 A9 D7 0A 00 00 00 00 00 43 F3 2B 3C 00 00 00 00 60 10 0D 00 A9 D7 0A 00 Mesh27: 00 01 36 00 1A 7D E5 3C 00 00 00 00 80 21 0D 00 CF EF 0A 00 00 00 36 00 1A 7D E5 3C 00 00 00 00 80 21 0D 00 CF EF 0A 00 Mesh30: 00 01 00 00 2D 7A D4 3C 00 00 00 00 C0 26 0D 00 BB F6 0A 00 00 00 00 00 2D 7A D4 3C 00 00 00 00 C0 26 0D 00 BB F6 0A 00 With all the edits done, you should get something like this:
  2. You should ask a moderator to split this thread, as all this animation stuff is off-topic. It would be more visible as its own thread. To answer your question, I don't know.
  3. The animation is literally called "stealth". It can be found in S_Male02 (i.e. it is shared by both sexes).
  4. A supermodel is the model that another model draws its animations from. For example, player models draw their animations from a chained series of supermodels with various shared and unique male/female animations. When the game tells the model to play a specific animation, it checks if that animation is included in the model, if not then it looks at the specified supermodel and checks it for the animation (and further on, if it also references a supermodel itself, like for players). "Super" in this sense just means "above", referring to the fact that the model with the animations is higher up the chain in terms of priority. The original C_Terentatek model has unique animations. For the scaled versions I just imported geometry only, scaled up the scene, changed the name of the AuroraBase, changed the animation scale value to match the world scale change, and then changed the supermodel from null to C_Terentatek. Thus the scaled versions have no inherent animations themselves, they rely on the original model for those.
  5. The squares are additional meshes with animated self-illum. The two main side panel meshes are hologlow01 and hologril01, with the top panel main mesh being mcholmach02. You then have 5 other meshes spread across the panels: Mesh27, Mesh30, Mesh117, Mesh118, Object181. They all share the same texture, LEH_scre02, they just have their self-illum values keyed to cycle between black and white. For example: node dummy Mesh27 parent M12aa_01fa selfillumcolorkey 0 0 0 0 0.266667008399963 1 1 1 0.533333003520966 0 0 0 0.766667008399963 1 1 1 1.03332996368408 0 0 0 1.29999995231628 1 1 1 1.56666994094849 0 0 0 1.79999995231628 1 1 1 2.09999990463257 0 0 0 2.40000009536743 1 1 1 2.70000004768372 0 0 0 2.96667003631592 1 1 1 3.2666699886322 0 0 0 endlist endnodeYour problem isn't a texture issue, it's a mesh issue. You'll need to hex edit all the relevant level models and set the render flags for those 5 meshes to 0.
  6. It's telling that what they have shown is mostly just environment stuff. A trained monkey can make props and level models (I should know, that's what I did in the aforementioned project). The real challenge is in gameplay: combat mechanics, scripting, AI, conversations/dialogue, UI, etc.
  7. Just to clarify, they use the original model as the supermodel, so you'll need an appearance.2da edit even if you want to replace the regular sized version (i.e. don't try changing the name of these models to C_Terentatek, point appearance.2da to these new models).
  8. The eyes use the face texture. Any mod that alters the eyes would be incompatible with any other face texture mod.
  9. Here you go. I did some quick tests and they seemed OK. If you want to have them in addition to the original sized version, you'll need to add some appearance.2da rows for them and edit UTCs as appropriate. https://www.darthparametric.com/files/kotor/k1/[K1]_Terentatek_Resized.7z
  10. Your April Fools 2018 mission, should you choose to accept it, is to troll the KOTOR sub with an M4-78 Apeiron gag. Something to the effect of "The M4-78 and Apeiron teams are delighted to announce an exclusivity agreement has been reached. Under the terms of the agreement, M4-78: Apeiron Edition will become the sole mod available for Apeiron". As someone who has previously worked on a large scale fan remake project, it's pretty obvious to me these guys lack the ability to produce anything of any real substance. It will be lucky to ever get to glorified tech demo stage.
  11. You are worried about lack of mods for a project that will never release?
  12. There's some pretty hardcore white knighting going on in that thread. I wonder if they are just delusional fanboys, or actual Apeiron members trying to defend/justify their work?
  13. It's easy enough to adjust the UVs in question: The problem is turning that into a functional game model. Taina's Replacer, the most practical way to make UV edits, throws an error when trying to write the MDX. Edit: Thanks to a mysterious benefactor whose secret alien technology allows for the functional compiling of models, I present this: https://www.darthparametric.com/files/kotor/k1/[K1]_Korriban_M36AA_01_UV_Edit.7z It's not perfect and could do with some further tweaking, but it seems like the edit didn't cause the level to explode, which is the most important thing. Try it out and let me know if there are any problems.
  14. That would be bad UVs. It's a common problem throughout the game. I doubt anyone has fixed it because editing level models is kind of a pain in the ass.
  15. Yeah, it's fairly trivial to do the scale. The only question is whether the models will compile properly. It's typically a case of role the dice every time you use MDLOps. What sort of size increase are you looking at? I'd suggest you may not want to go too big, or the combat animations probably won't align very well.
  16. So a laptop then? There's your problem. Low end integrated mobile graphics are terrible.
  17. There's no point anyway. Skinning is not something specific to KOTOR. There are a gazillion tutorials on the internet.
  18. It's not like it is a secret. There have been several ports of JKA models in the past, like the movie style robe models.
  19. The body proportions are fine, they just need some scaling and minor limb repositioning: It's the skinning the mesh to the KOTOR skeleton that is the primary issue.
  20. JK models are a bit of a pain with all the extra bits for limb dismemberment that need to be discarded, but that's not the real problem. Typically you'd need to reskin them from scratch, and unfortunately there just aren't many (or any?) skinners left in the KOTOR modding scene.
  21. Like requests for other JK2/JKA ports, your problem is almost certainly going to be that nobody is going to skin it to a KOTOR rig.
  22. JCarter is working on a complete replacement using a model I made - http://deadlystream.com/forum/topic/5176-jcs-mod-resource-collaboration-thread/ - and Malkior was working on a texture for it - http://deadlystream.com/forum/topic/5176-jcs-mod-resource-collaboration-thread/?p=54634
  23. In the Czerka level? Been years since I played a pansy Light Sider, so I can't remember if the Ithorians have their own version. Looks like 209TELw is the Czerka mainframe room level model. The texture list is: tel_cp01 tel_cp02 tel_fl01 tel_fl04 tel_fl05 tel_hcl1 tel_hl1 tel_ja04 tel_ja16 tel_lt03 tel_mon1 tel_mon2 tel_sstn6 tel_tr01 tel_tr04 tel_tr07 tel_wl03 tel_wl06 tel_wl07 And of those it looks like the ones you want are tel_cp01, tel_cp02, tel_mon1, tel_mon2 - I assume "computer panel" and "monitor".
  24. Only the specific cutscene animations exist (pacing back and forth, taking the mask off, etc.). That doesn't magically get you moving cape and belts animations for all the player combat, idles, walking, etc. animations. Those all had to be hand keyframed.
  25. Looks like a shader issue with your GPU. The stealth effect works fine for me on the Steam version. Are you running integrated graphics?