Lure of the Temptress - catastrophic path finding

[Lebostein]

It is very hard to play this game. The path finding drives me crazy:
- Often the different characters hinder himself, for example some characters blocks exits
- the main character don't walk to the target directly, it runs for example 2 times back and forth, up and down and find the path after some iterations

Other thing: it is impossible to play the game, because I have this bug:
http://sourceforge.net/p/scummvm/bugs/5340/
marked as fixed but with 1.7.0 I see the same behaviour. Ratpouch is switching between two rooms in an endless loop (two small rooms after escaping the prison). No change to pick him. Very strange. I have replayed the prison escape scene about 4 times and one time I could leave the rooms (and enter the city) with Ratpouch. But after walking through the town (until the city walls) Ratpouch disappeared again. I looked for him and I found him switching between the two first rooms again. It seems he walked back alone...

[Lebostein]

You should change the support status to "Untested". It is impossible to play the game here. Sometimes (if more than 4 NPCs are in the room) you have to wait 5 minutes to leave a room. Ratpouch disappears frequently (to stuck in the endless loop) and you have to reload an old savegame....

[LordHoto]

Please open a separate bug report for each issue you encounter.

[md5]

Regarding the issue with the other characters: that is how the original behaved. Characters would block exits quite often. So, unfortunately that's not a bug. Theoretically, we could allow the hero to walk past other characters, but that could lead to other issues.

I'm not sure about the issue with the main character walking back and forth. Do you have an example scene?

I did not experience the bug with Ratpouch myself (but it has been awhile since I Finished the game). Which version of ScummVM are you using?

Finally, as LordHoto says, please open a bug report for each of the issues you're experiencing. That will help us isolate and fix the problems.

Thanks!

[Lebostein]

I use ScummVM 1.7 with the german version of Lure. The game crashes very often. Sometimes I have to exit the game because I can no longer move around.

PS: This is the worst path finding I have ever seen in 20 years of gaming. In combination with the uncoordinated movement of the NPC's it is a horrible trip. If more then 4 NPC's in one room, you get a chaos and sometimes you have to wait 2 minutes until you can leave the room. But I have understand that this behaviour is the original behaviour. Very crazy.

[LordHoto]

I use ScummVM 1.7 with the german version of Lure. The game crashes very often. Sometimes I have to exit the game because I can no longer move around.

Please report bugs for all the crashes you are experiencing. This should not happen.

[Estranged2]

I procrastinated writing here for a whole year just because everyone else who dared to state the obvious was ignored and it seemed pointless.
But it has to be done.

I believe LOTT is a unique unappreciated accomplishment but today it can't be experienced properly.
The truly terrifying thing about the ScummVM version of LOTT is the desynchronization of EVERYTHING NPC related.

1) The game got many bad reviews on GoG and complaints on their forums simply because every time there are several NPCs you have to wait at least 10 times longer (compared to the DOS version) until they get out of your way and go to their destination. In the ScummVM version you can also enter infinite waiting loops that don't exist in the DOS version. In the DOS version you can take the largest number of NPCs possible on screen and they'll quickly sort their path without any waiting or problem. In DOS, your companion moves out of your way in a second and that's it. Here, there's a miscoordination between you and him and he enters incredible loops that can last a minute if there's a third person on the screen. So in this version (and only in this version!) NPCs make it very hard (sometimes impossible) for the player to just walk around, even when it's just you and your companion.

2) Background dialogue gets in the way of main dialogue and may also cause dangerous waiting loops which also doesn't happen in the original, especially in the taverns. In the original, background dialogue is not displayed and does not interrupt the main dialogue so no desynchronization problem can arise in the first place.

3) I have a save where after a lot of issues with 1) and 2) I was stuck in a state in which I can no longer click on characters to talk to them (this is when I quit and found that this never happens in the DOS version). People complain about another unavoidable showstopper deadlock introduced by the ScummVM version at the end of the game, in which they have to distract the drunk guard - which is impossible because of the ruined pathfinding. And there are many more reported on the GoG forums and reviews, I was just blocked much earlier to experience them personally.

4) There are also strings mentioning one object ("bottle") that are wrongly triggered for all objects - which doesn't happen in the original. As far as I remember, the bug was that every object you can't pick or do something with is "bottle" even if it's something else (this happens in the very first rooms).

5) This is a sidetrack, but it still has to be mentioned - The sound is unbearably disfigured (in the DOSBox version it can be fixed by forcing Sound Blaster in the Dosbox config file.) The Amiga version of the game has even better sound which is also possible to pull off in Dosbox but it's too much trouble to set up for a simple, ignorant user like me, even though someone wrote instructions about it. But I'd expect better from a ScummVM's port team who are not supposed to be simple users like me.

In the end the game is slower, more tedious, prone to showstopper bugs, and unpleasant to play in a way that it is NOT in DOSBox (in which I played it and finished it after trying ScummVM) and people incorrectly believe that this is how it was shipped back then. ScummVM/GOG are doing a great disservice to this masterpiece.

________________

When I played LOTT 1 year ago on GOG, I encountered the aforementioned showstopper, and I was lucky (and correct) to assume that it's impossible for Revolution to have shipped an adventure game in this state in the 90s. I found the abandonware DOS version. (It turned out that the DOSBox version has a "missing inventory item" anti-piracy problem that one has to go around, by restarting immediately after starting a new game, but other than that, there aren't any other obstacles to enjoying the game in its original form).

I could put the effort to go through the process and report the bugs I experienced, I could even record comparison videos between DOSBox and ScummVM to prove the glaringly obvious difference and delays, but I'm not sure if it will be worth it, because this hasn't bothered anyone for decades - neither Revolution Software, nor the developers at ScummVM here, who have denied that the bugs and delays are newly introduced. Reporting these issues sounds weird because these are issues that are immediately observable as soon as you get out of jail and just try to do normal things. The severe issues I mentioned are painfully obvious - one doesn't have to be a QA to see them, it's impossible NOT to see them if you play. I don't understand how they didn't get noticed and how they can be denied like this. If you run the two versions (ScummVM / Dosbox) side by side in the town it's undeniable that they are nothing alike.

I don't know much about ScummVM and I don't want to be disrespectful to a community of volunteers (as far as I understand) that love the masterpieces of the past. But the fact is that if this is the goal - preserving the masterpieces of the past - then LOTT has been misrepresented precisely because of this terribly broken version - this version has harmed it more than it has done any good. And LOTT has been in this state for more than a decade, which is very depressing.

[Praetorian]

Submitting bug reports properly on our bug tracker is the best way for a developer to notice them and try to resolve them.

Please, be as detailed as possible, provide save games and any other information (eg. build info, OS version, screenshots, link to gameplay showcasing the bug) that would help us understand and reproduce the issue faster.

The project is indeed based on volunteer work on our precious limited free time. It is also open source and anyone is more than welcome to study the engine code and submit a patch for issues they have spotted, if they have found a way to fix them. We very much appreciate those contributions.

[Estranged2]

I understand. Okay, I will have to do this, yes. I'll really be as detailed as I can for each bug, and I'll definitely have to upload YouTube videos to show the problems because most of them happen across time.

[criezy]

Your fifth points may be outdated. The sound in Lure of the Temptress (both AdLib and MT-32) was greatly improved recently.

[Estranged2]

Your fifth points may be outdated. The sound in Lure of the Temptress (both AdLib and MT-32) was greatly improved recently.

The last update in GoG I see is from the 25th of April 2018 and I have played after that. So I don't think I missed something.

[Praetorian]

Your fifth points may be outdated. The sound in Lure of the Temptress (both AdLib and MT-32) was greatly improved recently.

The last update in GoG I see is from the 25th of April 2018 and I have played after that. So I don't think I missed something.

Please, if possible, test with our daily development builds (snapshot builds) from our buildbot. The "latest" column reflects the latest state in the ScummVM codebase (bleeding edge code, bug fixes, not fully tested new features etc), and the "stable" column currently is the state of the code that will lead to the upcoming stable release of ScummVM. Either should be fine to test with, as long as the ScummVM version is 2.3.0 or above.
https://buildbot.scummvm.org/#/snapshots

I suspect that GOG is distributing the game with an old(er) version of ScummVM. Edit: I can confirm that GOG distributes the game with an older version of ScummVM (2.0.0 from Dec 9 2017). There have been a few newer stable releases of ScummVM since then.

[criezy]

And the sound improvements I mentioned are definitely not in that version used by GOG. They are not even included in the most recent ScummVM release (2.2.0). The next release will be the first one to include those. So for now the only way to get them is to use a daily development build (or compile the latest code yourself).

I am not aware of any recent improvements on the other points you mentioned, so those are probably still broken. The https://github.com/scummvm/scummvm/blob/master/NEWS.md file indicates that the fire animation in first room will be fixed in the next release as well. But no other fix is mentioned in recent releases.

[sev]

I procrastinated writing here for a whole year just because everyone else who dared to state the obvious was ignored and it seemed pointless.
But it has to be done.

....

I don't know much about ScummVM and I don't want to be disrespectful to a community of volunteers (as far as I understand) that love the masterpieces of the past. But the fact is that if this is the goal - preserving the masterpieces of the past - then LOTT has been misrepresented precisely because of this terribly broken version - this version has harmed it more than it has done any good. And LOTT has been in this state for more than a decade, which is very depressing.

Unfortunately, your message has done exactly the opposite. The level of discouragement for the developers who spend months on rewriting Assembly into C++ was only increased with your post, a post full of disrespect and attacks. I am sure, it was not your intention, and you're passionate about the game, but truly, spilling over negativity is much less effective than stating the facts.

If you think it "has to be done", learn some x86 Assembly and submit your patches. If you think, we are misrepresenting something and did a terrible job, The ScummVM project also helped to make the game freeware, use DOSBox. But please, abstain from attacking the team.


Eugene

[Estranged2]

I procrastinated writing here for a whole year just because everyone else who dared to state the obvious was ignored and it seemed pointless.
But it has to be done.

....

I don't know much about ScummVM and I don't want to be disrespectful to a community of volunteers (as far as I understand) that love the masterpieces of the past. But the fact is that if this is the goal - preserving the masterpieces of the past - then LOTT has been misrepresented precisely because of this terribly broken version - this version has harmed it more than it has done any good. And LOTT has been in this state for more than a decade, which is very depressing.

Unfortunately, your message has done exactly the opposite. The level of discouragement for the developers who spend months on rewriting Assembly into C++ was only increased with your post, a post full of disrespect and attacks. I am sure, it was not your intention, and you're passionate about the game, but truly, spilling over negativity is much less effective than stating the facts.

If you think it "has to be done", learn some x86 Assembly and submit your patches. If you think, we are misrepresenting something and did a terrible job, The ScummVM project also helped to make the game freeware, use DOSBox. But please, abstain from attacking the team.


Eugene

Hello, Eugene. I don't know what I would do or how I would feel in your shoes. I know though that I've been in a somewhat similar situation (shipping a buggy game after years of effort) and when confronted by disappointed users, I didn't try to deny the problems in the way it was done here. I also don't think there's any good move for a GOG LOTT player in this situation. People have already stated the facts in a neutral way years ago in this thread and elsewhere but the response was denial about the actual state of the port, and shifting the blame to the original game. Saying that "it used to be like that in the original anyway" when it actually wasn't, is something I would not do and that's the only criticism I have for how this was handled.

In general, I agree with what you've said.

You're right that I'm not helping my case. It's very hard for me to find a nice way to talk about a situation like this without omitting important parts of the truth. The fact is that this port was chosen by GoG/Revolution to represent the game to the public, and it has been misrepresenting it for years as buggy, tedious, and full of dead ends. GoG and Revolution obviously didn't care enough to do a basic walkthrough of the port to verify it so my trust especially in GoG as a "game museum" has been eroded as well.

You are right that it's easy to be negative and make demands, and it's hard to do work. I'm a simple level designer (ex-QA), I'm not a programmer, so I will find the time to do the work that I can do - to make a clear and detailed comparison that demonstrates the introduced bugs. This will still take time and effort even if it may be way less qualified work and way less time and energy spent than yours. Maybe it will be in vain, maybe not. If the volunteer programmers here are demotivated, and GoG and Revolution don't care, so be it. But I'll take time to document everything throughout this month.