Lure of the Temptress - catastrophic path finding

[criezy]

To give a bit of context, the engine for Lure of the Temptress was implemented before Revolution Software provided the original source code for the game. That means it had to be reverse engineered, which is a lot of tedious work. For the developer who spent many months during his free time to do this work and implement this engine, your comment could be seen as disparaging and depressing. He also spend a lot of time fixing bugs that were reported in our bug tracker. Also because a lot of things are randomised, some issues can be very difficult to debug. The original source code could potentially help fix issues, but the whole game was implemented in assembly, and pathfinding algorithms are often a complicated piece of code. And since the current engine was not based on the original source code, mapping the two could also be complicated. It might even be easier to reimplement large part of the engine based on the assembly source code rather than try to fix the existing code. So fixing those kind of bugs will sadly probably require a lot of time doing work that few developers find interesting.

Since they made the game available for free, I suspect neither GOG nor Revolution Software are interested in spending resources to work on this. So this will probably be up to a volunteer developer having the time and motivation to work on it. And such developers are in short supply.

I have not played the original game, so I don't know how it behaves. But I completed the game in ScummVM and I could clearly see that bumping into characters and trying to let them get out of the way was annoying. I didn't get any blocking bug, but maybe I was just lucky. And since you seem to have played it with the original executable, I trust you wen you say that it behaves in a better way.

But I'll take time to document everything throughout this month.

Thank you. Having detailed bug reports for the issue would certainly be a step toward getting those fixed. We had for example a bug report about broken AdLib implementation, so we knew about the issue, and it is now fixed (although it took many years). So hopefully a developer will see those in the future and decide that he wants to take a stab at fixing them.

We do have one bug report already about characters getting stuck in the Italian version (https://bugs.scummvm.org/ticket/7182). But I guess that bug is probably not specific to the Italian version. But I don't see any bug report about the other issues you mention.

[Estranged2]

I see.
It seems I'm still mentally 14, unfortunately.
I shouldn't have jumped to assumptions like this.

What a difficult situation.
Fixing it also seems close to impossible the way you describe it.
Now that I start thinking about it, maybe the desynchronization doesn't play out the same way on different machines. That's also worth testing.

I apologize. I'll try to do something useful soon and see if I know someone who can help, too.

[Kirben]

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.

Don't even try this on, these path finding issues have been known for a long time, along with the sound issues. The known sound issues in particular were never even documented at the time. The game should never have been bundled with ScummVM in GOG or retail releases, considering the state of the game engine at that time. There is a big difference between an alternative game engine been offered, and a replacement game engine been used at retail level.

The truth is ScummVM completely ruined the reputation of this game, but no one cares. I tried to get GOG to revert to using the original via DOXBox in the past numerous times, without any luck.

[eriktorbjorn]

Don't even try this on, these path finding issues have been known for a long time, along with the sound issues. The known sound issues in particular were never even documented at the time. The game should never have been bundled with ScummVM in GOG or retail releases, considering the state of the game engine at that time. There is a big difference between an alternative game engine been offered, and a replacement game engine been used at retail level.

Speaking only for myself, I didn't know about them. (Probably because I never played the game past the first few rooms.) And until I read this thread, I wasn't sure if the original source code had been located or not. I found references to it being lost. Sounds like the compatibility page should be updated, and bug reports filed (or reopened, if they were closed prematurely)?

[Kirben]

A rough timeline provides a better explanation:
The game was added to ScummVM
The game was stated as 95% complete, due to known issues (especially broken sound) never been documented.
The game was bundled with ScummVM, on GOG, due to working with Revolution Software.
Reports of the path finding issues started on GOG, and tended to be meet with hostility.
I realized the strange sound isn't normal, and that Adlib sound is broken (due to videos of original). I updated the compatibility page, and added related bug reports for the sound problems. This is actually game breaking, since it is difficult to find the blacksmith due to the broken sound, if you have not played the game before, and aren't using a walkthough.
I started requesting GOG switch to using DOSBox for the game, without success, due to lack of any direct contacts.
Revolution Software released a 25th Anniversary collection at retail, using ScummVM for the older games. I make an issue of the serious problems with Lure of the Temptress again, only to be meet with general lack of care.
The music and sound support has been improved greatly, due to the work of NMIError.

If the goal of ScummVM is to continue to work with companies to become the replacement game engine, then there is a responsibility to make sure a working version is provided, well tested, and resolve any problems that are reported. Otherwise the ScummVM project should become more of a tinker project for talented programmers to work on interesting game engines, without the burden of support and testing. There are still new game engines been added in a playable to complete state, but not feature complete state, with limitations not always been documented or stated in ScummVM (i.e. lack of Roland MT-32 support)

[Praetorian]

Please reopen, further comment on existing, or issue new bug reports on the remaining issues with the game. It is the only way a developer will eventually look into them and provide a patch, unless one of the developers in this thread is willing to provide a PR or direct code patch for them and working on them already, having fully grasped the cause the issue.

Active ScummVM developers' current priorities are hardly going to change if people are working on other stuff now, and it certainly does not help to take this matter in a accusatory tone, vague talk about hostility and responsibilities. People will get discouraged by this and this kind of pressure is not healthy for a member of a voluntary project.

Being polite, trying to maintain a calm tone even when frustrated helps. Being respectful, acknowledging the huge amount of work that goes into recreating engines from scratch should be a basic courtesy.

The nature of the project has not changed. It is voluntary. People work on their free time on tasks they love. A lot of time, we work even on expense of our non-free time or personal/family time to fix bugs we consider current high priority ones in a huge TODO list (which I'm sure every one in the project has). A personal list that on occasion changes based on bugs we see reported on the bug tracker.

Reporting bugs elsewhere does not help unless people willing to look into them and currently have the required spare time and relaxed schedule are aware of them. And it does not help that most times those bugs elsewhere are not reported in a much helpful and formal manner, lacking details and making them hard to reproduce (or even understand sometimes). A save game, a youtube link showcasing an issue, full details on ScummVM build, testing platform and conditions go a long way.

Testing is done continuously, by the developers, and the community. I'm sure GOG and the publishers do their testing as well.

But as every developer (and probably old time gamer) should know by now, bugs will always exist, regression will occasionally come up and some bugs may get low prioritized. We also don't all know of every bug of every engine. It is wrong to assume that. And we don't always get feedback for persisting bugs. Reporting them on the bug tracker and adding a comment on how an old bug is still persisting in a new version helps. Testing and providing more feedback helps. Having experience on how the original engine behaved helps a lot too.

However, this is not the place to resolve issues of GOG's or the publisher's support regardless of how disappointed one is. Those specific matters are not in our hands and other people (including me) here also have (had or currently still have) their own peeves, issues and complaints with games and their current published state.

I'm more thankful that old games are again published and are accessible to a larger player community through a legal venue. This means potentially more will play, test and report back. It means bugs will be fixed, maybe original game bugs too. Being mad about them or being dismissive of the attention the engines got from ScummVM, the years of disassembly work sometimes done by one person, is a choice, but it won't get the bugs fixed.

Lure of Temptress is even a freeware game so I'd expect way more people who have spotted bugs to have reported them or provided more info on the existing ones on the tracker.

Please, make use of the ScummVM bug tracker. Please, keep a calm and respectful tone in your posts here, considering of the work done by volunteering people. Try to actively find constructive ways to help improve a situation that you consider frustrating, not make it even more frustrating for others, too.

[Kirben]

Don't give me the sob story, it was 5 years ago I last mentioned these problems to the project leads. An email to the previous direct contacts at GOG & Revolution Software, to explain the problems, and get the package at GOG updated to DoxBox in the meantime, was all that was required. If that had happened even earlier, the 25th Anniversary Collection wouldn't have been effected.

The actual bugs in Lure in the Temptress can be fixed in the long term, the problem was leaving a broken game version at retail level, which ended up been re-used in the 25th Anniversary Collection. This wasn't a case of ScummVM been unexpectedly bundled with random games. I'm well aware of situations like MojoTouch, which are continuing to bundle software (specific languages, Roland ROMs) they are unlikely to even have the rights to.

There is still barely any testing of new games, let alone regression testing of older games with changes (i.e. recent changes in SCUMM). The shared backends system also has the disadvantage that changes to common code, can cause regressions in specific games. There is still no compatibility database, to track when games were even last known to be completable. Instead you continue to push untested major releases of ScummVM on people not expecting regressions.

Just continue making the same mistakes again, and ignore past problems. I don't know why I even bother anymore.

[eriktorbjorn]

There is still no compatibility database, to track when games were even last known to be completable. Instead you continue to push untested major releases of ScummVM on people not expecting regressions.

Well, that sounds like a good idea. (Maybe it's been discussed in the past, but because of life happening I haven't followed the project as closely as I used to.) I wouldn't know the first thing about how to set it up, but I could certainly have provided some data for when I played through the Mac versions of Indiana Jones and the Last Crusade, Loom, and Monkey Island 2 not that long ago...

It's unfortunate that some problems only get reported on the GOG and Steam forums, not the ScummVM bug tracker. I've found out about - and fixed - a couple of Zork: Grand Inquisitor bugs that way, but I have no way to get GOG to update to a newer version of ScummVM. So far I've restricted my bug reports to them to cases where they are shipping broken data files, and even that can be like pulling teeth. But I only tend to look at forums for games where I know I have at least a theoretical chance of fixing bugs (or it's a game that I have a personal interest in). I never played Lure of the Temptress back in the day, and I wouldn't be able to read the original source code even if I had it.

So for me, the list of known problems in Lure of the Temptress is limited to what I see in the bug tracker. At the time of writing, that's one unsupported demo version and a bug in the Italian version. A quick glance at the GOG forum didn't give me much more than that. If there was hostility there, I missed it.

[Praetorian]

Don't give me the sob story, (...)
Just continue making the same mistakes again, and ignore past problems. I don't know why I even bother anymore.

Open bug tracker tickets or provide a Pull Request with a fix then. See, no sob story.

[sev]

There is still barely any testing of new games, let alone regression testing of older games with changes (i.e. recent changes in SCUMM). The shared backends system also has the disadvantage that changes to common code, can cause regressions in specific games. There is still no compatibility database, to track when games were even last known to be completable. Instead you continue to push untested major releases of ScummVM on people not expecting regressions.

Just continue making the same mistakes again, and ignore past problems. I don't know why I even bother anymore.

Well, you know how the project is operating: we do not have dedicated QAs neither there is a way of having them and we heavily rely on the users' testing and submitting the results of their playtests. You yourself are a capable and skilful developer, so you could actually help with fixing the bugs, even this very Lure of the Temptress pathfinding. Maybe it is a perfect opportunity to remember the past and spend some time on hacking? If no time for hacking, help us with the playtesting? We are preparing the next release right now and just as it was happening in the last years, the activity of users helping with playtesting is lukewarm, to say the least. Thus, we again will be pushing a release with potential regressions.


Eugene

[Estranged2]

I followed the link to the bug tracker posted above.
I'm sorry but I really couldn't figure it out.

How do you even post a bug?

I think nobody has reported this for years, because there are too many obstacles in their way, at least 3 funnels:

1) They have to realize that it's not a problem coming from the original game
2) They have to realize they have to take their problem here, not to GoG
3) And finally, after posting on the forum, they are directed to the bug tracker and they have to figure out the bug tracker.

What should I be looking for, here? I hope there's a big colourful button "Create" somewhere, like in Jira?
I really tried to find it.

To put yourself in the shoes of a user, I'll just say I could never figure out how to download anything from GutHub for years until I was recently explained that in GitHub, you download by pressing a button labelled... "Code". Of course, I'd never press "Code", because I don't feel I have the right - I'm not a programmer and I don't have a license to code, I just want to download the thing.

I also tried to read FAQ and HELP/GUIDE and the closest relevant thing I found was this section:

Preset Values for New Tickets.
To create a link to the new-ticket form filled with preset values, you need to call the /newticket? URL with variable=value separated by &.

Uh... This is where I knew that this is beyond me.

...This month I'll try to record some comparison videos.
But... you're saying you're already making another version of LOTT? Or you're making another version of ScummVM? Is there a deadline? At the same time, the fixes won't end up on GoG? So even if the broken pathfinding / wrong strings / background dialogue sequences are fixed, that won't get updated on GoG?

[Praetorian]

I followed the link to the bug tracker posted above.
I'm sorry but I really couldn't figure it out.

How do you even post a bug?

You need to login first with your Github account.

You log in from here:


Then, you create a ticket by clicking on New Ticket.


The documentation here should help with what you should include in your ticket:
https://docs.scummvm.org/en/latest/help ... _bugs.html

Here's a link with a list of the existing open tickets for the Lure Engine:
https://bugs.scummvm.org/query?status=n ... changetime

These are all the tickets we have on Lure (closed and open, some are feature requests and not a bug/defect):
https://bugs.scummvm.org/query?status=c ... changetime

(And these are all the open tickets we currently have - not representative of all the tasks the developers are working on):
https://bugs.scummvm.org/query?status=n ... changetime

But... you're saying you're already making another version of LOTT? Or you're making another version of ScummVM? Is there a deadline? At the same time, the fixes won't end up on GoG? So even if the broken pathfinding / wrong strings / background dialogue sequences are fixed, that won't get updated on GoG?

There is an upcoming new stable release of ScummVM. There is a call for help with testing to the user community.
viewtopic.php?f=1&t=16362

GOG does update the ScummVM version they bundle with games. It has done it from time to time, especially if there's significant reason to do so (major bugs fixed). I wouldn't worry about that now. First the bug(s) have to be fixed.

[Estranged2]

Thank you for the information! I don't have a GitHub account because I've always seen GitHub as scary - "don't go there, mortal!". I'll make an account, of course, since it's necessary. I just have to point out though that you can't really expect many players to report anything if they have to go through many steps. I've lived in the DOS days and I've optimized my autoexec.bat and himem.sys but even as a somewhat advanced user I've always seen computers as arcane and scary. On the other hand, it's a good way to filter out careless reporting, but maybe you filter too much to the point that you hardly get anything. I suppose some things can't be made simpler than they can be, though. Anyway, thanks again.

[MusicallyInspired]

It's just as many steps as signing up for a forum account and making a post.

[sev]

I just have to point out though that you can't really expect many players to report anything if they have to go through many steps.

The reason is very very simple: we need a way to connect to the reporter back. For that, we'd need to have their e-mail address, and we use GitHub for that, so we do not have to store that information on our servers and have one less security problem to care about.

If we allow anonymous bug submissions, this will suck the team resources for processing those reports, but most importantly, will open a wide door to all kinds of spam. Our earlier experiments with allowing anonymous posting on our Wiki ended up with bots flooding the spam in mere minutes after we open.

And by the way, this is why we have forum rule #3a "do not post bugreports here".


Eugene