DarthParametric

Well in a request thread, if the OP isn't looking for a response, then either someone fulfilled the request, or nobody ever did. If someone fulfilled the request, but the link is dead (highly likely in old DS threads, since it nukes old attachments), then I think it is appropriate for someone to necro the thread and ask if anyone still has a copy rather than make a new thread. If nobody ever fulfilled the request, then it depends on the nature of the new posts. A bunch of "me too!" posts adds nothing and should be considered bumping. Anyone actively trying to fulfil the request by creating a new mod should be encouraged to do so, since fostering the creation of new content should be the primary goal of DS, but perhaps they could be gently mod/admin-assisted in migrating to a WIP thread instead. I guess the point is that there need to be some rules around "low effort" necroing, but I don't think that it should be banned outright. Blanket rules are tools of the lazy and can needlessly stifle discussion/creativity. It's really a kind of case-by-case situation.

What matters is not the necroing of a thread as much as the reason/purpose behind it. If there's a thread about an unsolved bug or issue, and suddenly 3 years after the last post someone posts a solution, that's good content. However, if some numbnuts just starts randomly posting inane conversational posts in ancient threads that add nothing then that should be an infraction, akin to people bumping threads with multiple posts. Since this is often a habit of new members, I have long been in favour of manual moderation for any new member's first five or so posts, as is common policy on some other forums. No, I think public floggings are appropriate. There needs to be a demonstrable result of people's actions that others can observe. And hopefully learn from (but I wouldn't hold my breath).

Not that I can recall (or nobody would bother with GLIntercept). What's the button combo on Xbox?

There are snapshots, but you are probably hitting the issue of extraneous crap being included in the URL. I noticed that happening when I had a look yesterday. Not sure what it is exactly. Seems like it is from the LF side though. I don't recall encountering it before.

No, you can just edit the ASCII. MDLEdit may let you edit it directly, otherwise use a text editor. Either way, you'll need to compile against the new supermodel, so you'll also need S_Female02.mdl/mdx in the same directory. For the animation scale, the vanilla Vandar scale using the male supermodel is 0.278. We know that the female model is 0.944 times the size of the male supermodel, therefore a scale of 0.262 should be appropriate.

It's just a matter of editing the model and pointing it to S_Female02 and changing the animation scale. Not particularly difficult.

He presumably lacks the feats to use one. His model also probably lacks a bunch of combat animations, since it uses S_Male02 as the supermodel.

You can already see the trouble - backface culling. Just like Max, Odyssey does not render the backfaces of polygons. Which means what you see in the viewport there is exactly what you'd see in the game. While there would be a head in the way of most of it, not all of it will be obscured. Not necessarily. You give all the faces that you want continuous smoothing across the same group. Anywhere you want a hard edge, those adjoining polys need separate groups.

No, that's not how it works at all. The problem you had is that the droid is indeed set to non-destroyable by its OnSpawn script. I then made a mistake in the script I posted above, using the wrong nth creature - 1 instead of 0. So it should be: object oDroid = GetObjectByTag("dan15_ancientdrd", 0); Your original bit for that would have worked, since you omitted it and it would default to 0. You just lacked the required setting it to destroyable first. Here's a test with fade enabled so you can see it working.

You can try running SetIsDestroyable on it first. You also don't need to use DelayCommand with fade ins/outs, as the first term already specifies the delay. Try this: void main() { object oDroid = GetObjectByTag("dan15_ancientdrd", 0); ActionPauseConversation(); SetGlobalFadeOut(0.0, 0.5); AssignCommand(oDroid, SetIsDestroyable(TRUE, FALSE, FALSE)); DelayCommand(1.0, DestroyObject(oDroid, 0.0, TRUE)); SetGlobalFadeIn(2.0, 0.5); ActionWait(2.5); ActionResumeConversation(); } When using DestroyObject, you'll typically want to enable the No Fade option (second term) when doing a quick off-screen destroy. Any terms left out will inherit the default values on compile. Check out nwscript.nss for more info.

No, your "NCS" files in the archive are just renamed NSS. Open them in a text editor and you'll see.

Lol, I didn't even look. Yeah these are just NSS that are renamed. Well there's your problem.

If you are requesting help, it would be wise to include script source, not just binaries. DeNCS won't decompile either.

There should be a 0.2s delay to destroy the existing NPCs, and a 0.5s delay to spawn them back - i.e. 0.3s apart. So yes, it's possible there might be some collision interference from "ghost Bastila" I guess. You could try padding the spawn-in by another few milliseconds to see if that helps at all. Alternatively, there's always the woodshed technique. You could also try switching to a stated location instead of doing a GetLocation from a waypoint. Not that that should make any difference, but the game is kind of screwy with waypoints. Regarding the fade out, yes, that is a known problem because they didn't set the NoFade flag in DestroyObject to TRUE. It's fixed in the revised version I have for K1CP that also fixes Juhani missing a state save like all the other party members, but I never got around to adding that before the release of 1.8. Just be aware that k_pebn_pophawk resref is used in all the EH modules, so it must be injected into a MOD unless you want to bork the Lehon sequence.

All party members get destroyed and respawned by the module OnLoad. They should always spawn at the same waypoint rather than having anything to do with the player. Unless the player was standing on top of the waypoint (which should be impossible).

You deleted too much. You should just select the polys you want to delete, not the verts if you aren't 100% sure what you are doing. As to how to model the collar itself, there are many ways to skin a cat. What matters most is that the end result looks good and there are no gaps. Looking at what you have there, I'd say you need to weld the verts and/or adjust the smoothing groups to get an idea of what the final result will be.

Not anything like what you can render out of Terragen, etc., no. I'm trying to think of a way you could render a moving cloud layer keeping the sun backlighting.

Ah, well yeah then that probably won't work then I guess. The only other way would be a second cloud dome using transparency. That could then move (or have scrolling UVs), with the rear/original skydome being static with just the sky and sun.

Hrmm... I wonder how it would go if the skybox had scrolling UVs for a bit of cloud movement? That might require converting it into a single mesh though.

Yes, it works on 10. All versions of 10 should be 64bit.

Sitters need to be a full body model, since for placeables there is no provision to specify a separate head like with parts models in appearance.2da as happens for characters. As there is no regular "high poly" Twi'lek full body model, you'll need to create your own in Max/GMax by merging the appropriate separate head and body models. Edit: Also, be aware that K1 has a very small row limit for placeables.2da, so it is highly advisable not to add new placeable entries.

You'll probably want to do some in-game testing and see what the feedback log says to make sure they didn''t just skip scripting and hardcode it all.

Probably.