DarthParametric

Whoops. That was an oversight on my part. I only did a cursory check. I thought the illuminated meshes were laying over the top, so didn't notice the gaps. Sorry about that. To fix it, we have to tackle it a different way. We'll need to edit the keyframe data for the animations to stop the self-illumination cycling. Start by decompiling the M12AA_01F model and open the ASCII output in a text editor. Search for the term "newanim" and you'll be taken down to the bottom of the file where the animation data is. Browsing through it, there are 11 meshes with animated self-illum, Mesh118, Mesh117, Object178, Object179, Object180, Object181, Object182, Object183, Mesh27, Mesh30, and Object189 (all children of dummy object M12AA_01FA). Looking at the model in Max, we can ignore Object189 as that is a light strip. There's also an AuroraLight with keyed colour, which we don't need to worry about. Of the 10 remaining meshes, there's the five in the center holoprojector I covered in the previous post, and the rest are scattered around the walls of the room. I assume that you will also want to edit these this time. The base static control panel meshes have their self-illum set to white, so we'll need to edit these blinking meshes so they have their self-illum always set to white as well. Open the binary model in the MDLOps data viewer. This time, we'll be looking in a different section, under Animations. If you expand the "animloop1" node, then under "nodes" you'll find the data for the individual objects: If we refer back to the ASCII file, we'll see the keyframe data for the first object, Mesh118: node dummy Mesh118 parent M12aa_01fa selfillumcolorkey 0 1 1 1 0.300000011920929 0 0 0 0.633333027362823 1 1 1 0.933332979679108 0 0 0 1.2333300113678 1 1 1 1.5 0 0 0 1.7666699886322 1 1 1 2 0 0 0 2.29999995231628 1 1 1 2.59999990463257 0 0 0 2.93333005905151 1 1 1 3.2666699886322 1 1 1 endlist endnode What we see here are 12 keyframes that are switching the value for self-illum between black (0 0 0) and white (1 1 1), which is how you get the lights blinking on and off. If we expand the node for Mesh118 in the Data Viewer and select "controllerdata" we see the following: In the right panel we can see it's pretty obvious our keyframe data comprises the values from 012 to 047. Looking at the hex, it's clear that 1 1 1 is 00 00 80 3F 00 00 80 3F 00 00 80 3F and 0 0 0 is 00 00 00 00 00 00 00 00 00 00 00 00. If we do a search for the entire keyframe chunk in a hex editor: 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F we only find a single instance: So we can replace it with data to change every keyframe to 1 1 1, like so: 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F Mesh117 only has two keyframes, so we need to search for the entire controller data chunk: 00 00 00 00 1F 11 51 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80 3F 00 00 80 3F 00 00 80 3F Which again we find a single instance of, right below the chunk we just edited: We can replace that with: 00 00 00 00 1F 11 51 40 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F Repeat for the remaining objects. For Object178 you'll want to add the hex values from the "controllers" chunk as well to give you enough to work with. Note that this is identical to the data for Object180, so you can replace both in one go. Here are the search and replace hex chunks: It should be noted that you may end up with a bit of a halo around these meshes by virtue of the fact that they are physically separate. There's not really anything you can do about that without physically altering the meshes themselves. Hopefully it is less noticeable with a proper texture, but it might be problematic with a pale/light colour.

I think he would greatly benefit from a Sean Connery-style chest beard.

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:

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.

The animation is literally called "stealth". It can be found in S_Male02 (i.e. it is shared by both sexes).

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.

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.

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.

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).

The eyes use the face texture. Any mod that alters the eyes would be incompatible with any other face texture mod.

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

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.

You are worried about lack of mods for a project that will never release?

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?

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.

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.

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.

So a laptop then? There's your problem. Low end integrated mobile graphics are terrible.

There's no point anyway. Skinning is not something specific to KOTOR. There are a gazillion tutorials on the internet.

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.

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.

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.

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.

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

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".