Playing TSL for PC finally (with mods), will post observations and questions as I go.

[ZeldaTheSwordsman 40]

Well, after finally getting the GOG version of TSL, quicktesting it, and installing TSLRCM, M4-78, and a few other mods... I got around to starting a proper game this evening, playing the prologue as I always do.

The first hitch that I discovered was a tendency for the first subtitle in a "cutscene"-type dialogue sequence to be skipped (sometimes, but not always, accompanied by the screen slooowly letterboxing). K1 has the same problem, so I suspect it's a vanilla issue with the Odyssey engine itself.
The second problem I encountered was a volume balance issue with bark bubble voiceovers - like the one about bashing a container open - sometimes being very quiet and drowned out by ambient noise. Minor, but worth noting.

Something more annoying happened shortly after I went the Ebon Hawk's exterior. I clicked on the port quadlaser before being down on its level. T3-M4 promptly tried to make a beeline for it, got hung up on the ledge, and didn't unstick from it until I switched to 3C-FD and deactivated solo mode. I didn't fully realize what was the matter, however.

When I went back inside and decided to go check out the Starboard Dormitory after unlocking it, I ran into a silly glitch. I switched party members while in front of the inner garage door... and wound up forcing 3C-FD through it and into the garage! 😆

It was while messing about in there that I discovered what seems to be a significant problem with TSL's controls on the PC version: The movement keys don't cancel the auto-movement triggered by clicking on containers, the workbench, terminals (except for the Galaxy Map), and some doors (it affected the Outer Garage Door, for instance, but not the Main Hold Containment Door). Nor does there seem to be any other way to cancel it. Once you click on something, you're locked into making a beeline for it until you get there (unless you switch characters) - this is what got T3 stuck earlier. I tested this over and over; no matter how long I held a movement key after clicking on something, the character wouldn't stop auto-moving towards it until they reached it. Testing on a fresh file let me discover there were a few things - the Galaxy Map and the Main Hold Containment Door, not sure about others - I could turn away from, but the problem is present for most things.
That.... is some severe jank. The Xbox versions of TSL and K1 don't have this problem. The PC version of K1 (at least as found in the Best of PC collection) also doesn't have this problem, although it can be a bit sticky about canceling out of the auto-movement.
Is this a vanilla issue with TSL for PC, or did some mod combo break things? I'll answer the bug report questionnaire just in case

1) During the game, when did the problem begin to occur?
While playing the prologue

2) Did you install the latest version of the mod? That's TSLRCM 1.8.6 and M4-78 1.5 (or M4-78 version 1.3 if you're using the Workshop version). We only provide assistance for the most current version of those mods.
Yes to both.

3) What version of the game do you have? (Steam, GOG, 4CD, KotOR Collection?) What region is the game designed for if it's the 4 CD version?
GOG

4) Did you update your game as required by your game's region? (4-CD version ONLY)
N/A

5) Did you install this over the previous version(s), or did you perform a fresh installation as required by the TSLRCM's read-me file?
Fresh installation

6) What other mods have you installed? Please give an accurate list and provide links to each of these mods - even if they are found on this site. (We don't actually know them all!.)
Alright, I'll provide links. Had to copypaste them from an outside document though because the janky rich text editor on this site makes them either display a preview that buries the next text line, or makes them overwrite each other if you try pasting as plaintext links.
https://deadlystream.com/files/file/1004-alternate-revan-romances-updated/?tab=comments
https://deadlystream.com/files/file/428-extended-enclave-tslrcm-add-on/
https://deadlystream.com/files/file/416-tsl-clone-wars-armors/
https://deadlystream.com/files/file/1374-harbinger-hull-fixes/
https://deadlystream.com/files/file/1275-peragus-administration-level-room-model-fixes/
https://deadlystream.com/files/file/1773-k2-star-forge-robes-in-ebon-hawk-container/ (Initially incorrectly)
https://www.gamefront.com/games/knights-of-the-old-republic-ii/file/revan-s-robes-star-forge-robes-for-tsl

7) Can you be more specific about the error? At what point did it happen?

The first time I tried to abort and change direction after clicking on something.

 

8 ) Have you tried re-downloading/re-installing the mod?
I did re-install one mod. I deleted the utp from the "Star Forge Robes in Ebon Hawk Container" mod, installed the  "Revans Robes/Star Forge Robes for TSL" mod that mod depends on, and then reinstalled that one. Just in case this was the problem.
The rest... I'm waiting to hear if this is a vanilla problem before going through the hassle.

9) Have you tried using a different save game?
Not on the affected character.

10) Have you tried starting a new game?
Yes. I discovered some nuances at this point - there were actually a few things I could cancel the auto-movement towards, but for most it remained irrevocable (and canceling it for the Galaxy Map isn't 100% reliable).

11) What Operating System do you use? (List Virtual Machines as well if you are using them.)

Windows 7

12) Can you confirm that you see the TSLRCM logo on the the main menu screen?
Yes. And it still hasn't been fixed to reflect the mod being 1.8.6 lol

13) What language is your game set for?
English

14) Which language of TSLRCM are you using?
English

15) Are you playing this on a laptop or a desktop computer?
Desktop

16) Did you install TSLRCM after you started your game?
Not unless making quickstart characters that never got so much as an autosave counts.

Edited July 2, 2021 by ZeldaTheSwordsman
Use this as a catchall instead of making a million new threads

[Thor110 497]

4 hours ago, ZeldaTheSwordsman said:

That.... is some severe jank. The Xbox versions of TSL and K1 don't have this problem. The PC version of K1 (at least as found in the Best of PC collection) also doesn't have this problem, although it can be a bit sticky about canceling out of the auto-movement.
Is this a vanilla issue with TSL for PC, or did some mod combo break things? I'll answer the bug report questionnaire just in case

I think you are imagining things.

I find that you need to press the next movement button for at least a second before it will let you cancel the movement.

I just ran a quick test with a footlocker, a swoop bike and an NPC and I have no problems cancelling out of the movement.

So in short, I have never experienced this issue, but I have certainly noticed that it doesn't always feel like it lets you, but that's probably more down to the timing of everything than it is the game.

[ZeldaTheSwordsman 40]

7 minutes ago, Thor110 said:

I think you are imagining things.

I find that you need to press the next movement button for at least a second before it will let you cancel the movement.

I just ran a quick test with a footlocker, a swoop bike and an NPC and I have no problems cancelling out of the movement.

So in short, I have never experienced this issue, but I have certainly noticed that it doesn't always feel like it lets you, but that's probably more down to the timing of everything than it is the game.

1. A second or more of input lag is still a problem IMO.
2. I am not imagining things:

4 hours ago, ZeldaTheSwordsman said:

I tested this over and over; no matter how long I held a movement key after clicking on something, the character wouldn't stop auto-moving towards it until they reached it. Testing on a fresh file let me discover there were a few things - the Galaxy Map and the Main Hold Containment Door, not sure about others - I could turn away from, but the problem is present for most things.

I made sure to test from as far away as I could on things like the Workbench and Sparking Wires in the garage. I would hold the key down immediately after clicking, and T3 would refuse to deviate course every single time. And heck, before the deliberate testing I had tried holding down movement keys for sustained periods during the incident of T3 getting hung up on the ledge trying to reach the quadlaser (which counts as a container) - no response then either.

Thank you for testing all the same, that gave me hope that the issue could be fixed.

And in fact... while I was writing this post, it occurred to me to test something I saw mentioned in connection with a similar issue (being unable to move after combat): Making sure Vsync was enabled. It's off by default, at least in the GOG version.

I tried turning it on, and lo and behold suddenly movement canceling was working properly.

...Things like this make me want to see the Odyssey engine's code be released to the public domain, just so we can figure out what the crap even.

[Thor110 497]

On 6/26/2021 at 2:14 PM, ZeldaTheSwordsman said:

1. A second or more of input lag is still a problem IMO.
2. I am not imagining things:

I am not certain on the timing or how it is on the original Xbox, but I find it isn't as delayed if you force it by say clicking both mouse buttons or clicking a mouse button and pressing a movement key.

What I usually do is use a mouse button to swing the camera around and then press the direction I want to change to going after I have clicked on an object, I find that works better than just trying one key.

Maybe not, I will have to properly try it out on the original Xbox at some point but overall it seems to work fine for me and a second might even be me overstating it.

Perhaps it is where an Analog would usually be in play on the Xbox but is not on the PC.

On 6/26/2021 at 2:14 PM, ZeldaTheSwordsman said:

I made sure to test from as far away as I could on things like the Workbench and Sparking Wires in the garage. I would hold the key down immediately after clicking, and T3 would refuse to deviate course every single time. And heck, before the deliberate testing I had tried holding down movement keys for sustained periods during the incident of T3 getting hung up on the ledge trying to reach the quadlaser (which counts as a container) - no response then either.

Thank you for testing all the same, that gave me hope that the issue could be fixed.

Maybe it is just T3, I can't say I have tested or played that level in a while to be honest. No worries.

On 6/26/2021 at 2:14 PM, ZeldaTheSwordsman said:

And in fact... while I was writing this post, it occurred to me to test something I saw mentioned in connection with a similar issue (being unable to move after combat): Making sure Vsync was enabled. It's off by default, at least in the GOG version.

I tried turning it on, and lo and behold suddenly movement canceling was working properly.

...Things like this make me want to see the Odyssey engine's code be released to the public domain, just so we can figure out what the crap even.

Oh well that would make sense, I am surprised it wasn't and that you hadn't tried tweaking the settings. Either way it works now.

That certainly would be great, but their are alternatives or open source engine reimplementation's for KotOR that are looking to be quite promising.

I would say maybe one day they will but it is attached to the Star Wars IP so it is unlikely.

Thor110

[ZeldaTheSwordsman 40]

So, I discovered that holograms in TSL still work with Frame Buffer Effects disabled - that was a surprise. But they don't look normal - the horizontal banding seems a lot more intense, and instead of the flickering light level normally seen they have an energy shimmer similar to what Stealth Fields look like without frame buffer effects. This shimmer has a habit of lighting up the eyeballs, which looks... off.

EDIT:

It occurs to me that there's a phenomenon in TSL that might be an overlooked bug: If you skip the prologue you get to keep everything you found in it, but you lose it if you properly finish the prologue. That... feels like it should be the other way around.

[ZeldaTheSwordsman 40]

Posting this here to avoid making a million new threads..

So, I'm currently messing around on Nar Shaddaa. And a few questions have come up.

1. Not sure how well reverting Fassa to Toydarian works. I don't think the "Supposed to be Quello" speculation holds up, since Andrew Secombe gives Quello a different accent (I was slightly surprised to learn it was him) while Fassa's voice is nigh-identical to Watto. That being said, I think both his Toydarian and Twi'lek forms could use an overhaul (as could the Twi'lek Domo he shares his vanilla appearance with); "Bleached Watto with intact dentition" (same skin as Quello) and "plain brown tunic" don't exactly seem fitting for his position; I think there might be a mod for the vanilla appearance, but I haven't seen anything for the TSLRCM form. The Twi'lek form could use either armor or a fancier outfit, the Toydarian one could use adornment and a more normal coloration.

2. On my savefile where I got all the available quests at the flophouse, I screwed up and saved again after blowing the chance to investigate the G0-T0 bug on the swoop droid by backing out of it. I decided to try editing globals with KSE to restore the chance rather than go through the slight inconvenience of re-getting the quests. Possibly a mistake, since it opened a slight rabbit hole and I haven't got anywhere with it.

I didn't see anything in the Booleans that seemed it could possibly affect this, the only things I found that looked likely were in the Numerics.

I first tried resetting 000_Goto_Swoop to 0 (it had been set to 1 after I backed out of the opportunity), to see if that would do it. No dice.

Checking with another save made after getting the codes from Borna Lys but before checking the droid showed that while 000_Goto_Swoop was set to 0, 301NAR_Goto_Swoop was set to 1 (it was 0 on a save before getting the codes, and on the save made after blowing the chance to check the bug). I thought maybe 000_Goto_Crimes might be the culprit, since it was higher by 1 on the save made after the botch, but checking showed that not to be the case; 000_Goto_Crimes incremented immediately after getting the codes.

With this information in mind, I tried changing 301NAR_Goto_Swoop to 1 on the post-botch save. Still didn't show the "[Awareness] Check the droid for oddities" prompt.

A save made after successfully examining the bug shows 000_Goto_Swoop: 0 and 301NAR_Goto_Swoop: 1, the same as before checking the droid (but after you get the codes). So that didn't help.

What am I missing that determines whether or not you're allowed to find and examine the bug?

UPDATE: Noticed that 300NAR_Exchange_Favor was 255 instead of 0 and that 300NAR_Exchange_Gap had incremented from 3 to 4 on both the file where I found the bug but backed out of messing with it, and the file where I examined it. So I tried reverting them to the state they were on files where I hadn't messed with the bug (that is 300NAR_Exchange_Favor: 0, 300NAR_Exchange_Gap: 3), yet still I don't get the "Check the droid for oddities" prompt.

So obviously, I'm still missing something.

[ZeldaTheSwordsman 40]

More observations to share, including some done with the help of an unmodded install.

1. On further reflection, Fassa getting changed to a Twi'lek seems sketchy - it reeks to me of being done to avoid paying Andrew Secombe more royalties. Still think the Toydarian appearance could use an overhaul.
2. Regarding the Twi'Lek Domo... To go into more detail, here's what he looks like when you meet him in the cantina to be recruited as a dancer:

A plain brown tunic, making him identical to Fassa's vanilla appearance and the hapless Twi'lek spice trader who gets gunned down by thugs who think your blundering onto the scene is an ambush. That.. really doesn't seem right for a majordomo. And it would seem to be a mistake, at least to my thinking.

In the Jekk'Jekk Tarr, you run into this fellow - also a Rutian Twi'lek and also identified as "Twi'lek Domo". Perhaps they were meant to be one and the same (although that has timeline issues if you don't do the dancing until after the JJT). In any case, he has a much fancier outfit (aside from the suspiciously jeans-like pants) that actually looks the part. Giving this outfit to the one who hires you to dance seems like a good idea for a mod, I might actually see if I can do that myself.

2. The airspeeder parking is... bugged. In the loading screen for the docks (which defies screenshots), you can see the airspeeder parked in the air beside the Pylon 1 walkway, neatly lined up with the gap in the railings, with the "repulsorlift forks" (as I think of them) pointed towards the main walkway. However, when you actually take the speeder to the docks in-game...


...it ends up misaligned. It's pointed the wrong way, slightly over the walkway, and not lined up neatly with the railing gap (these last two leave it clipping through part of the fence).

It likewise overhangs the walkable area and clips through fencing in the parking spot in the landing pad area. Maybe a little less blatant due to how the positioning of the speeder body overlaps the fence, but definitely noticeable.

The issue is at its most subtle in the Refugee Quad, enough to be ignorable.

Is the speeder parking something we can fix with modding?

4. So, about the holograms. Turns out those shimmer lines weren't due to frame buffer effects being disabled after all.

That means the paler tinge and the shimmer lines were caused by a mod, not sure which.

5. I wonder how tough it would be to give the refugees the Outcast rags from the first game. It would help them look more like they're in the rough shape the story says they are, help distinguish them from the commoners.