Opened 11 years ago
Closed 7 years ago
#6247 closed defect (fixed)
SCI: QFG3: Hero's actions in battle too fast
| Reported by: | SF/eoakford | Owned by: | m-kiewitz |
|---|---|---|---|
| Priority: | normal | Component: | Engine: SCI |
| Version: | Keywords: | original script | |
| Cc: | Game: | Quest for Glory 3 |
Description
One of the things that the NRS speed patch fixed was that the Hero's actions in battle now happened at a realistic speed. Without this patch, the Hero attacks at light-speed. This hasn't yet been fixed in ScummVM.
ScummVM version: 1.6.0git2625-gadc338c Language: English Version: 1.1 Platform: Win32
Ticket imported from: #3604938. Ticket imported from: bugs/6247.
Attachments (2)
Change History (12)
by , 11 years ago
comment:1 by , 11 years ago
| Summary: | Hero's actions in battle too fast without NRS patch → SCI: QFG3: Hero's actions in battle too fast |
|---|
comment:2 by , 11 years ago
Have to check the behavior of this one... the NRS patch hacks the game scripts in QFG3 in a very peculiar way. Have you got a savegame from the original interpreter?
by , 11 years ago
| Attachment: | fastbattle.zip added |
|---|
Pre-battle saves from original interpreter, both with and without NRS patch applied.
comment:3 by , 11 years ago
Yeah, I got them, both with and without the NRS patch (if that matters).
comment:4 by , 8 years ago
| Owner: | set to |
|---|---|
| Resolution: | → fixed |
| Status: | new → pending |
comment:5 by , 8 years ago
This should be fixed with commit 3cf34d64177021d7620f80846ffb582029226f38
It also happened in the original interpreter when the machine was too powerful. Our speed throttler was also not triggered, because Sierra used an inner loop for the combat, that didn't do things that the main loop normally does.
So I had to make 2 script patches in total.
We would like to tag the 1.8.0 release in 2 days. I hope you are available at the moment to check. I'm not 100% sure how fast the hero is supposed to move, but I can now modify that easily.
comment:6 by , 8 years ago
| Keywords: | original added |
|---|
comment:7 by , 8 years ago
There may be a second part to the problem. The speed was always an issue, but the fact that the Hero's combat actions could be cancelled without being full performed made for unrealistic training. So you could wait for your attack action to slice, then straight away slice again, or cast spells repeatedly without "finishing" the previous cast. Worse, you can just hold the key or spam the mouse on the action and gain (valuable) skill without effort in little real time.
I think the speed is OK, for what it's worth, but it's still "too fast" in the sense described above.
comment:8 by , 8 years ago
Is this exclusive to ScummVM or did it also happen, when using the original interpreter?
comment:9 by , 8 years ago
I'd say it was always there, although not always visible...
I recall on my 386 it was so slow to receive events (between everything else it was trying to do) that spamming buttons didn't get you far. The later computers certainly showed it up more readily.
comment:10 by , 7 years ago
| Status: | pending → closed |
|---|
Pre-Battle Save