Skip to content

Can anyone brief me on the current workings of the engine regarding a few things?

carugacaruga Member Posts: 375
edited June 2012 in Archive (General Discussion)
Was just reading through the g3 fixpack docs and come across entries like:
The various spells and abilities that allow party members to transform are a bit of a mess. They're pretty good about cleaning up leftover abilities if you shift to a form and then back to human, but if you start going directly between forms without returning to human and/or mixing in transformations from items (i.e. Cloak of the Sewers) you can be left with a lot of spell cruft by the time you're back to human. We patch many of the transformation spells to be more thorough in cleaning out leftover spells and abilities. This patch also corrects an oversight where the Cloak of the Wolf had no way for the wearer to return to human form prior to the expiration of the spell.
EDIT: better example:
Melf's Acid Arrow Fixes

Melf's Acid Arrow can be resisted by magic resistance, but the accompanying portrait icon was not.
Even better:
Blindness Not Always Causing 'Blinded' String or Portrait Icon

Some spells and effects that cause blindness were not being accompanied by portrait icons and messages indicating that the target had been blinded.
What is going through the back of my mind when reading things like this is: do the game's systems have any sort of inheritance in regards to cleanup code and such, i.e. for example a common 'spell' script that has a prefix and postfix script that attaches to any narrower spell script that another spell inherits, and ensures the integrity of game-state (sanity checking and garbage-collecting); or do you have to hand-write everything, with lots of code-duplication?

I've seen instances where tweeting birds float above my character's head even though no status effects are attached to my character portrait. This tells me either that the engine doesn't have inheritable script-logic, or it isn't using it maximally, to be able to snare such inconsistencies across the board without having to cut&paste checks everywhere, and make sure that, in this case for example, the status effect, its icon, and the visual attached to the character sprite are all mutually inclusive (I mention garbage collection; in this case the tweeting birds are the 'garbage').
Post edited by caruga on

Comments

  • carugacaruga Member Posts: 375
    edited June 2012
    Also, less to do with inheritance, here's another fix:
    While in the 'cool down' period, the THAC0 penalty was being applied but not reflected in the character sheet.
    In other words, the text on the character sheet has to be updated manually, instead of the code automatically tracking and enumerating all THAC0 modifiers and the character sheet obtains the textual information by reference (can strings concatenate with variables?). Is it possible for the engine to work in the latter manner?

    Heck, I'd like to see an engine (or a soft-coded layer) where you can write a new value into the variable and the game will automatically update the presently-displayed string using hooks, rather than the programmer having to tell the graphic to be redrawn in-code.
  • WispWisp Member Posts: 1,102
    Other than the actual casting of the spells, there are no scripts involved in spells. A spell is a binary data structure. The cleaning up and book-keeping and such is handled by effects (substructures attached to the spell structure).
    In the case of the transformation spells, the problem was that the transform-to spells have give-spell-X effects, but the transform-back spells did not always have effects to remove the spells. Furthermore, the transform-to rarely removed the spells granted by another transform-to, nor did the second transform-to's transform-back remove them.

    Each effect has a field for whether it respects MR, and in the case of Melf's, one effect did while the other did not.

    Effects are generally rather narrow, e.g., we have the 'blind' effect, which imposes the THAC0 penalty and cuts visual range, but does not itself cause an icon to be displayed, or show a feed-back string in the dialogue bar. For the icon and the feed-back, you need two more effects.

    It is a bit intricate, and this sort of stuff probably accounts for a good percentage of the fixes in the G3 Fixpack.

    IIRC, the THAC0 thing was that the (en)rage ability used a THAC0-mod effect that does not update the character sheet. The fix was to use the other effect, that does update the sheet.
  • carugacaruga Member Posts: 375

    Each effect has a field for whether it respects MR, and in the case of Melf's, one effect did while the other did not.
    It seems inappropriate to me that an 'effect' for applying the status effect and the 'effect' of the icon representing it are invoked separately. As one possible solution, those two effects should be able to be chained together in causative order, so you only have to refer to the effect at the beginning of the chain and bypass one set of checks for all.

    I wonder if in the EE binary, the data structure you speak of could be interpreted by a macro/script-driven part of the engine, and it could be refined and enhanced by modders, assuming they don't already refine it themselves.
  • ElysElys Member Posts: 100
    edited June 2012

    It seems inappropriate to me that an 'effect' for applying the status effect and the 'effect' of the icon representing it are invoked separately.
    It's more flexible but so incidentally more prone to human error. (For example you can use same icon for two different spells.) They are technically invoked separately but still declared together as part of a unique spell properties. It just happens in this case, that when the spell was created, one MR flag setting of one effect was forgotten to be set.

Sign In or Register to comment.

2024 Overhaul Games, a division of Beamdog. © 2024 Hasbro, Inc. All Rights Reserved. Baldur's Gate, Dungeons & Dragons, D&D, Forgotten Realms, Baldur's Gate, Wizards of the Coast and their logos are trademarks of Wizards of the Coast LLC in the U.S.A. and other countries, and are used with permission. Hasbro and its logo are trademarks of Hasbro, Inc. and are used with permission. © 1998 BioWare Corp. All Rights Reserved. BioWare, the BioWare Infinity Engine and the BioWare logo are trademarks of Bioware Corp. Black Isle Studios and the Black Isle Studios logo are trademarks of Interplay Entertainment Corp. Atari and the Atari logo are trademarks owned by Atari Interactive, Inc. All other trademarks are the property of their respective owners.