Opened 8 years ago
Closed 2 years ago
#7133 closed defect (wontfix)
SCI: QFG3: Fighter / Paladin Zap spell training
| Reported by: | tomasz89 | Owned by: | sluicebox |
|---|---|---|---|
| Priority: | normal | Component: | Engine: SCI |
| Version: | Keywords: | ||
| Cc: | Game: | Quest for Glory 3 |
Description
ScummVM 1.9.0git1795-g6aec692 (May 13 2016 22:42:29) on Ubuntu 16.04. Quest for Glory 3 - from the Quest for Glory Anthology (no Belzorash patches).
Zap can't be trained as a Fighter or Paladin as it only increases skill inside of combat, which is rightfully not possible for these classes. Casting it "works" but deducts zero mana (instead of 3).
This is an issue in the original game and represents a more general problem of several spells not being trainable in the savannah (such as open). I've attached a save in the inn room as, despite the honour deductions, it is possible to train just about every other spell in that location.
Ticket imported from: bugs/7133.
Attachments (1)
Change History (14)
by , 8 years ago
comment:1 by , 8 years ago
comment:2 by , 8 years ago
QFG3 is has buggy casting scripts as you cannot train spells for no understandable reason in some rooms; therefore I assume it to be a script bug. When you are in the inn room in Tarna, all spells are trainable except zap.
You know a spell is trainable in the room you are in because when you cast a spell and it "works", mana points are deducted. Casting it lots in this case would train the spell. One example is the very starting room (Kreesha); it states it's an OK place for practicing magic, yet casting any spell deducts no mana and thus you cannot train them.
However, Zap is particularly quirky. The only classes that can train it are mages and thieves as it can only be built up when cast during combat, and fighters/paladins cannot switch to the casting interface.
It is my understanding therefore that there is a script that has some condition on the deduction of mana points and casting of spells that doesn't work in some rooms. The patch would, where casting spells are permitted, deduct mana and allow the spell to be trained up as in the case of the inn room. Zap is just one corner case.
Hope that makes sense.
comment:3 by , 8 years ago
Thanks for the explanation - it does make sense now.
I also found this explanation in the Quest for Glory Omnipedia:
The spell is trained by being cast repeatedly. In Quest for Glory III, the spell can only be trained when it is cast in combat. Casting outside of combat will not train the spell or use up any mana points. Fighter/Paladin hybrids are not able to train the spell in this game since they cannot access the Magic User's combat menu. Despite a weapon only being able to carry a single charge at one time, the spell can be continually cast and will be properly trained.
I'll take a look later.
comment:4 by , 8 years ago
| Summary: | Fighter / Paladin Zap spell training → SCI: QFG3: Fighter / Paladin Zap spell training |
|---|
comment:5 by , 8 years ago
I studied the game scripts, and I'm not convinced this is not intentional. Here's what I found:
Spells are handled by a few scripts, but the main logic goes like this:
- Spell instances in script #21 handle the hand click event on the spell icon.
- The spell instance checks if the current room is in a white-list of rooms that the spell supports.
- If the room is supported, the matching spell verb is dispatched to the room.
- The room instance checks if the spell can be handled, and if so - will call
ego::castSpell(spell). ego::castSpell()checks for available mana points, consumes mana points, and awards spell skill points.
The Batlle room (#500) handling of spells is a different, and I won't go into that.
It can be seen that the matching of spells to rooms is done by 2 lists: one maintained by the spell instance, and one by the room. Only if both lists agree there's a match - then ego::castSpell() will be called.
There are cases where there's a match only in the first list (Detect Magic supports Kreesha's room, but not the other way around), and there are cases where there's a match only in the 2nd list (The Savanna room supports the Dazzle spell, but not the other way around). These cases are probably (minor) bugs.
However, the Zap spell is consistent: it only supports the Initiation room, and the Initiation room is the only room that supports the Zap spell. This is probably not a coincidence, so I'm not convinced we should change that logic.
As a reference, I compiled a list of the spells supported by each room. I didn't make the the opposite list of rooms supported by each spell.
comment:6 by , 8 years ago
Thanks for looking in to it. I believe you are asserting the game mechanics for the eligibility of spell casting, from which I can tell, is correct as you say. However, it is when the spell is cast (in eligble rooms) that strange things happen. From a black box perspective, looking at the game mechanics as a player, it just does not make sense to not deduct mana and train up the spells in rooms where the spell is allowed to be cast.
(side note: I understand the "initiation" room to be the magical duel room in the Leopardman village, with the Shaman?)
The game does indeed let you "cast" the spell - the effects generally work however no mana is deducted and the spell does not skill up with repeated casts. One example is casting detect magic in the Pool of Peace - it shows up the symbol for peace but no mana is deducted. Clearly the effect is happening, some internal mechanics seem to be incorrect.
Why should only a jungle room be suitable for training (most) spells, not a savannah room?
Why would it let me cast a zap spell in other rooms, tell me my weapon is charged (I can't tell whether that is actually true or not but the message leads the gamer to assume yes), but not deduct mana and train up the spell despite repeated casts?
In certain rooms like the streets of Tarna, the cast icon is disabled - it seems more logical to me that if they wanted to block spells being cast they would have done it this way; not allow the cast and effect but not deduct mana.
I believe it is some bug resulting out of the summon staff spell and effect. I believe that the intent for QFG3 summon staff was to allow spells to be cast without deducting mana and training the spell and somehow this logic is mixed up with the non-summon staff case. The fact that it only affects some rooms seems to confuse the issue more.
Given how the other games work to train spells (in QFG1/2 and 4, any eligble room for spell casting deducts mana and trains up the skill for that spell) the logic seems incorrect in QFG3. QFG4 summon staff works in the same way as QFG3, but all the spells are trainable and deduct mana properly in rooms where it is OK to cast a spell and the staff is not in use.
QFG5 is quite different so I've deliberately omitted talking about it.
I'm interested in your thoughts and thanks for your time.
comment:7 by , 8 years ago
You are correct that the game let's you "cast" Zap in eligible rooms, but it doesn't call the castSpell function which is responsible for the mana and skill adjustment. In essence - the scripts split the side effects of the spell on the world (showing the symbol of peace) and the side effects of the spell on the player (mana and skill). The latter only happens in the cases I described above. The former happens when the spell is being cast (through a different mechanism). That's why casting Zap actually charges the sword (flipping a bit the the sword is charged), but does not consume mana or award skill points.
I agree that this seem like an akward implementation choice. But this is not some small bug in few scripts. This is how the spell system is implemented. Fixing this would probably require a re-write of that system - which I think is outside the scope of this project.
Making small changes such as supporting the Zap spell in the eligible rooms is certainly doable - but I'm not convinced that omitting it was not intentional for the reasons I outlined above.
Have you tried contacting the Coles about this?
comment:8 by , 8 years ago
Thanks again for your work. I'd be honoured to contact the Coles! It would be the best way to understand what was intended here.
I'll report back once there is something new to add.
comment:9 by , 8 years ago
Corey responded to me:
"Most likely, none of the issues you are seeing were a matter of intent; they were probably sloppy programming. Spellcasting anywhere in the game should have gone through the centralized spellcasting class functions. Those were designed to have the side-effects you mention - increasing skill in that spell, and indirectly in Magic and Intelligence."
"Zap should work identically in and out of combat. Your assessment of the intent of the system is correct."
He gave some reasons as to why the complexity you've seen exists (or at least why the system was misunderstood compared to other games): "I was the lead programmer for the first two games, but almost completely uninvolved with QG3 except in the early design phase and towards the end of the game when I helped edit and clean up game messages." "It isn't surprising that there were some bugs and inconsistencies in some of the games. They used an X86 architecture in which all of the code and game data for a scene had to fit in a single 64KB block of memory along with all of the system classes and global code/data such as the skill system, character stats, and so on."
So while it was part of the original game programming, in all likelihood, it was not intended to be this way.
Now, how do you want to go about fixing this mess? :)
comment:10 by , 8 years ago
Thank you for reaching out to Corey - it's very interesting!
As I said before, rewriting the spell system is probably outside the scope of this project (but I might be wrong - I'm just a contributer - not a member). However, you can try and pitch this project to the members of the sciprogramming.com community. Some might find it a fun challenge, and do it. The community certainly have the tools to write such SCI patches.
Another option that might be in the scope of ScummVM is to simply enable using Zap correctly in the relevant rooms (Inn, Simabni's hero room, Savanna, Jungle, Kreesha). I can take a stab at this, but first I'd like to make sure that ScummVM will allow changing the game in such a way.
I'll try to raise a discussion about it.
follow-up: 12 comment:11 by , 5 years ago
There's a bunch of patches here: https://github.com/AshLancer/QFG3-Fan-Patch
One mentions this very problem (and another related/similar one):
- Fighters and Paladins can now train Zap outside of combat.
- You can now train Open and Detect Magic on the Savannah or Jungle screens (where it won't cause you to lose honor). You can also train any spell in Kreesha's magic shop if you want.
- Fixed spellcasting issues for every single room in the game.
Can those changes be adapted?
comment:12 by , 5 years ago
Replying to tomasz89:
There's a bunch of patches here: https://github.com/AshLancer/QFG3-Fan-Patch
Also see general request https://bugs.scummvm.org/ticket/11373
comment:13 by , 2 years ago
| Owner: | set to |
|---|---|
| Resolution: | → wontfix |
| Status: | new → closed |
I've looked into this and talked to md5 about it, we agree that this is out of scope for ScummVM. For better or worse, the RPG-stat logic is what makes the QFG games what they are, whether they make sense or not. I know a discord server of QFG fans that would be upset if we started editorializing those rules. Also, I'm not sure we could patch this if we wanted to, and we wouldn't know what to change it to.
Ash's fan patch is the place to go to for these kinds of fundamental improvements. The *huge* number of fixes it contains, all written by someone who knows the game thoroughly, demonstrates what it takes to really fix this game at a high level. You have to rewrite and restructure entire scripts, that amounts to hundreds of changes. It's beyond we can or should or want to do, and that's why we happily support Ash's fan patch. (I make sure all my QFG3 script patches are compatible with it.)
I don't fully understand the issue. What would a possible fix do?