Opened 6 years ago

Closed 2 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
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)

qfg3.090 (43.3 KB) - added by SF/eoakford 6 years ago.
Pre-Battle Save
fastbattle.zip (36.0 KB) - added by SF/eoakford 6 years ago.
Pre-battle saves from original interpreter, both with and without NRS patch applied.

Download all attachments as: .zip

Change History (12)

Changed 6 years ago by SF/eoakford

Attachment: qfg3.090 added

Pre-Battle Save

comment:1 Changed 6 years ago by SF/eoakford

Summary: Hero's actions in battle too fast without NRS patchSCI: QFG3: Hero's actions in battle too fast

comment:2 Changed 6 years ago by bluegr

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?

Changed 6 years ago by SF/eoakford

Attachment: fastbattle.zip added

Pre-battle saves from original interpreter, both with and without NRS patch applied.

comment:3 Changed 6 years ago by SF/eoakford

Yeah, I got them, both with and without the NRS patch (if that matters).

comment:4 Changed 3 years ago by m-kiewitz

Owner: set to m-kiewitz
Resolution: fixed
Status: newpending

comment:5 Changed 3 years ago by m-kiewitz

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 Changed 3 years ago by m-kiewitz

Keywords: original added

comment:7 Changed 3 years ago by tomasz89

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 Changed 3 years ago by m-kiewitz

Is this exclusive to ScummVM or did it also happen, when using the original interpreter?

comment:9 Changed 3 years ago by tomasz89

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 Changed 2 years ago by sev-

Status: pendingclosed
Note: See TracTickets for help on using tickets.