DarthParametric

Well there was a period where they were still using their own colocated server hardware which would regularly fall over, but supposedly they transitioned to proper virtual server hosting some time back. I don't know what the current issue is, or how long it will last, but the site was up only a few days ago.

Here you go, in the back room between Sakarie and Kiph where Panar and Bakkel lurk:

They already have some in the Onderon cantina as I recall. Shouldn't be too big a deal to replicate those in the Nar Shaddaa cantina, maybe in the entrance way. Although that's also a prime spot for a wall sign indicating strippers dancers and booze to the right, illicit gambling den to the left.

Spawning via script was for ease of testing purposes. Placing them via a GIT edit/MOD file is the "proper" way to do it for a public release version. You do one or the other, not both. If you wanted a SWTOR-style sign, it would probably be best as a simple 2D plane, like these: Model-wise, that's fairly straight forward, and if you want animation that's just in the texture. You'd set them up as new placeables and spawn them via the GIT, just like the billboards that Jorak Uln posted earlier.

There were script edits over at LucasForums which would allow you to skip both the Taris and Leviathan turret sections, but the site appears to be down again. Here it is in the event it comes back up: http://www.lucasforums.com/showthread.php?t=179868 Fortunately you can still see it via a Google cache (Wayback Machine doesn't seem to have it). While tygaran provided source for the Taris script k_ren_taris03: #include "k_inc_debug" #include "k_inc_stunt" void main() { StartNewModule("ebo_m12aa", "K_TARIS_DESTROYED", "11b", "", "", "", "", ""); }allowing a new copy of that to be compiled, unfortunately TK102 only attached a ZIP file of the Leviathan script to his post, without posting the source as text or even mentioning the script filename. I had a brief poke through the Leviathan scripts, but didn't see anything obvious. Perhaps someone else can chime in with an independently created script for that.

I wonder if you could use elements from the textures for C_ConDrdBoss, C_ConDrdL, and C_ConDrdM as a basis? They are all basically the same series with obvious shared similarities, yet those three have 1024x1024 diffuse textures and normal maps, yet C_ForDrd just has a 512x512 diffuse. It may require a remap to accommodate that though, which is likely more trouble than it is worth.

That's pretty much the way it has always been, end-users being in favour of the open season model, anything on the internet being fair game. Of course modders are not all of one mind. There are certainly those that advocate basically the open source model for mods. I recall running into a faction of them with Dragon Age Origins modding, back 5 or 6 years ago, where they were almost militant in their open source zeal. There was a period there with some pretty nasty inter-modder factional hostility.

All the mods that Nexus archived were already archived by the Wayback Machine. That was only GameFront though. Whatever wasn't already there from KOTOR Files was lost years ago.

This belongs in the request forum. Apparently ninja moderators are amongst us, lurking in the shadows. All the Gamefront-hosted mods are still available. Can't find what the mirrored KF link to Gamefront was, so that leaves the Nexus harvested version - http://www.nexusmods.com/kotor/mods/144

The problem is the easiest way to discover offsets for various information is via compiling slightly different versions of a single ASCII model with MDLOps and comparing them, but MDLOps adds some confusion into the mix because of the way it works. For example, look at this test model compiled with MDLOps: The self-illum values are no longer the final bytes of the Controller Data chunk like there were in the above example, instead they are before a (presumed) blank/buffer block and the alpha value. Now for the game this doesn't pose a problem, as the model itself specifies what values can be found at what offsets within the file. But for people blindly hex editing, lack of consistency becomes a serious pain in the ass. It's difficult to make a tutorial saying "do XYZ", because in many situations that may not apply. In other words, the above example is less "here's how you do this" as much as "here's what I did for this specific model". What would be really useful (albeit almost certainly never going to happen) would be some sort of built-in hex editing functionality for the MDLOps Data Viewer. If it identified/labelled select values for a given mesh like self-illum, ambient/diffuse, etc. and 0-1 flags like render, shadow, etc. and let you change their values and save out a new file, that would be great. But like I said, I doubt that is likely to ever happen.

The texture itself is irrelevant, inasmuch as self-illumination is controlled by the mesh. KOTOR only supports one texture per mesh, so level models comprise a whole bunch of separate meshes. In order to change the self-illum for those lights, you need to find the MDL for that particular room/chunk of the level, decompile it, open it up in Max/GMax, and find the mesh/meshes that you need to edit. In this case, the model in question would appear to be 151HAR08. For that room there are two meshes that comprise all the light sections. The ones that consists of the strips between the seats and one doorway offscreen in that pic (the second doorway is part of the adjoining MDL) and already has self-illum enabled is named HAR08_LITE_01. Interestingly, the second mesh that comprises the strips on the ceiling, under the windows, and at either end of the seats is also named HAR08_LITE_01, which is pretty atypical. It does actually have some self-illum, but the colour (which determines intensity) is set at a grey of 80,80,80, instead of the white 255,255,255 like the other mesh. If we compare the two meshes in the ASCII MDL, we can see the first mesh has: selfillumcolor 1 1 1 and the second mesh has something like: selfillumcolor 0.313726007938385 0.313726007938385 0.313726007938385 Now that we know what we are looking for, we need to extract a copy of the original MDL/MDX and open it up in MDLOps. Hit the Read button, then the View Data button. Expand the Nodes tree to expose the meshes. Normally your mesh (or meshes) would have a unique name, but in this instance we know from the hierarchy that the mesh we are interested in the second one of that name in the list. So scroll down until you get to the second instance of HAR08_LITE_01 (node #18 in this case) and expand it, like so: The last 12 bytes of the Controller Data chunk represents the self-illum (0.313726007938385 0.313726007938385 0.313726007938385) values: In this case, it equates to a hex value of B2A0A03E B2A0A03E B2A0A03E. If we check the other light mesh (node #15), we can see its self-illum value, 1 1 1, which is what we want to replicate: Which equates to a hex value of 0000803F 0000803F 0000803F. Now we can open up 151har08.mdl in a hex editor, and search for the hex string B2A0A03EB2A0A03EB2A0A03E. In this example it's easy, as there is only a single instance: It's a simple matter of replacing those bytes with the string 0000803F0000803F0000803F: In other cases it may not be so simple. For example if you search for 0000803F0000803F0000803F, you'll find 32 instances in that MDL. So for cases like that, you may need to include surrounding bytes in your search until you find a unique example. In this case, you might use the entire Controller Data chunk, seeing as it is pretty short. For the first light mesh, that would be 00000000 AA102FBE 2558E83F AE47A13F 00000000 00000000 00000000 00000000 0000803F 00000000 0000803F 00000000 0000803F 00000000 0000803F 0000803F 0000803F In this case there are two instances of that chunk, but it is fairly easy to spot the one we want by the surrounding bytes. For instance the preceding 64000000 FFFF0100 0D000E00 036EC501, which is the last 16 bytes of the Controllers chunk: So there you go, a crash course in hex editing for fun and profit. Here's the hex edited model from the example - http://dpmods.wheb.org/files/kotor/tsl/[TSL]_151HAR08_Self-Illum_Edit.7z

Those specific meshes in the level model would need their self-illum values hex edited.

You need to edit portraits.2da. That's the one that controls head textures.

It doesn't affect the textures. All it does is edit the model to change the render flag from 1 to 0 for the four meshes that make up the end platform. They are still there, they just aren't being rendered by the engine. It won't have any affect on the rest of the game.

Here, extract this into your Override and see what happens: http://dpmods.wheb.org/files/kotor/k1/[K1]_Manaan_Speeder_Track_MDL_Edit.7z

Nothing practical I would think. For one thing the textures are generic Manaan ones, (middle strip is LMG_Manwall09, side strips are LMG_Manfloor01, railings are LMG_Manwall15) so you'd have to hex edit the level model to use unique texture names to avoid causing issues elsewhere in that and other Manaan levels. For another, presumably any other textures are going to be similarly affected. It could be a GPU/driver issue perhaps. Do you know if it looks like this for everyone? I don't think I've ever bothered with the swoop races beyond the required one on Taris, so I have no personal experience of it. You could maybe try editing the model to raise the platform slightly so the water is no longer above it, but my previous attempts at that sort of thing haven't gone so hot, so maybe someone more familiar with level editing can chime in. One possibility might be just hiding the platform center sections altogether. That is easy enough to do with a simple hex edit, switching the mesh render flag.

I don't think the problem is the platform texture per se, it's the fact that there are multiple water planes that overlay and clip through the surface of the pad. Observe: Presumably the texture semantics that allow for the water effect have an adverse influence on anything they overlay.

For the dead Bioware link, use this - https://web.archive.org/web/20070209092240/http://nwn.bioware.com/developers/

Ah, so it is more of a MDLOps issue then, unsurprisingly. Scale could be useful for placeables, given they are static. I'd suspect it wouldn't be so great for animated meshes like characters (I'd have though Bioware would have just used that instead of having small/medium/large bodies if it worked).

Porting discussion lockdown in 3, 2, 1....

Maybe not great news for anyone that just started playing in the last week or two, but if you are planning on playing SWTOR, you might want to hold off for a few more days: http://www.swtor.com/dark-vs-light/ Basically you get rewards for every new character you create and level to 50 (and above for higher tiers) after the event starts on June 28. More info here: http://www.swtor.com/blog/dark-vs.-light-event-and-rewards-blog and here: http://swtorista.com/articles/swtor-dark-vs-light-event-list/ It kinda sucks for anyone who has already levelled all the classes, especially multiple times, but it's probably a great time to be someone new to the game.

I tried playing around with some trimesh options and comparing the compiled results. Test model was a simple cube trimesh (8 verts, 12 faces, 24 tverts) and an AuroraBase. Here's what I found. "scale" - Float. Default is 1.0. Changing it yielded no result. Compiled models were identical regardless. "transparencyhint" - Int. Default is 0. Changing it yielded no result. Compiled models were identical regardless. "alpha" - Float. Default is 1.0. 2 Bytes. http://dpimages.wheb.org/KOTOR_MDL_Test_01_Alpha.jpg "render" - Int., 0 or 1. Default is 1. 1 Byte (?). 1 = 256. ID'd in CChargin's data table (common mesh header, although # is different) http://dpimages.wheb.org/KOTOR_MDL_Test_02_Render.jpg "shadow" - Int., 0 or 1. Default is 0. 1 Byte (?).. 1 = 256. ID'd in CChargin's data table (common mesh header, although # is different) http://dpimages.wheb.org/KOTOR_MDL_Test_03_Shadow.jpg "rotatetexture" - Int., 0 or 1. Default is 0. Changing it yielded no result. Compiled models were identical regardless. "beaming" - Int., 0 or 1. Default is 0. Changing it yielded no result. Compiled models were identical regardless. "inheritcolor" - Int., 0 or 1. Default is 0. Changing it yielded no result. Compiled models were identical regardless. "tilefade" - Int. Appears it has 4 set values. 0 for "not a cap", 1 for "fadable, 2 for "base", 4 for "neighbour". Default is 0. Changing it yielded no result. Compiled models were identical regardless. I assume all those values that did nothing are redundant Aurora options that NWMax spits out. Or at the very least MDLOps just ignores them.

My HK model references the original HK model as the supermodel. It's not compatible with the melee mod because that mod changes the base HK model to a skinned mesh using the Wookiee rig and the standard Human animations. There's no way to "make" it compatible without replicating the same trick, and I have zero interest in doing so.

I have a bunch of characters on the US west coast server Harbinger. I also have few (mostly/all Republic I think) low to mid level chars on the EU RP server Progenitor, but as I mentioned in a reply to LiliArch's status I haven't really looked at them since launch.

Could you use a script to destroy the character at the end of the conversation and then spawn in a new non-interactive character that uses the same appearance?