Opened 12 years ago

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

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

Download all attachments as: .zip

Change History (12)

by SF/eoakford, 12 years ago

Attachment: qfg3.090 added

Pre-Battle Save

comment:1 by SF/eoakford, 12 years ago

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

comment:2 by bluegr, 12 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 SF/eoakford, 12 years ago

Attachment: fastbattle.zip added

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

comment:3 by SF/eoakford, 12 years ago

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

comment:4 by m-kiewitz, 9 years ago

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

comment:5 by m-kiewitz, 9 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 m-kiewitz, 9 years ago

Keywords: original added

comment:7 by tomasz89, 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 m-kiewitz, 8 years ago

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

comment:9 by tomasz89, 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 sev-, 8 years ago

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