Ascension64 Posted July 17, 2010 Share Posted July 17, 2010 Following on from the post in http://www.shsforums.net/topic/43639-bg2to...post__p__492220, I would like to discuss concordance of new features between GemRB and TobEx. Basically, the issue is how we can maintain consistency between implementations of new opcodes or opcode details (scripting or effect), or other externalisations (such as STRREFs to 2DAs) between implementations in TobEx that go into mainstream use and GemRB. For example, if opcode #3 gets a new type 4, TobEx implements that behaviour, and mod use of that new features becomes mainstream, can we guarantee that GemRB will implement this in the same way? So far, I have tried to avoid adding new features to TobEx, sticking to removing hard-coded limitations and bugfixing. Taimon's tob_hacks introduced some new features to effect opcodes, while a contributor to TobEx has requested addition of new features to certain effect opcodes. I imagine that any new features will need good justification before implementation and use. Overall, if you are happy to implement into GemRB reasonable feature additions to TobEx that become widely used, then that would be convenient for all parties. Happy to hear any thoughts on this issue. Link to comment
Galactygon Posted July 17, 2010 Share Posted July 17, 2010 We're reading minds, just cross-sent a PM to Avenger. -Galactygon Link to comment
Avenger Posted July 17, 2010 Share Posted July 17, 2010 Yes, this is a good idea. I sent Galactygon some that i remembered (and restricted info only to the ToB part). We externalize a lot (almost anything), but having some order is good. Additional info (new or changed actions/triggers): HasItemTypeSlot - you can check if someone has weapon or shield in second hand etc. IsWeather - trigger for weather types (you can check if it is raining, so your npcs can run under cover) 399 ApplySpellPoint[RES] - trivial 398 ChangeDestination(O:Object*,S:Destination*) alters a travel trigger (this is used to simulate a hardcoded iwd feature) 397 UnmakeGlobal(O:Object*) - just the opposite of MakeGlobal, removes an actor from the .gam structure, and make it a regular creature. 396 SetToken2DA(S:ResRef*) - sets up multiple tokens, randomly, based on a 2da (basically the 2da rowname is the token, and the columns are the possible values). This could be used to set up random names, like: Bartender john joe will Will set the bartender token randomly to john, joe or will. OnIsland(I:index) - this is used in HoW only. If the int0Parameter is 0, it will work like the original (but uses island00.2da) Otherwise 1-9 would use island0x.2da for the region to check. Link to comment
Galactygon Posted July 17, 2010 Share Posted July 17, 2010 I'm posting Avenger's reply: Yes, we have already added a few new opcodes/actions and such.If you are interested only in ToB, then it is less obvious. Also improved some file formats. Especially the .pro format. (Mostly to be able to implement all hard coded projectiles in a generic way). DLTCEP even supports the new .pro fields. I don't really remember all our changes, but here are a few that should be very useful: 1. journal entry groups. AddJournalEntry's 3rd parameter is the group field. SetQuestDone will automagically remove all journal entries belonging to the group (also in its 3rd parameter). It is stored in the journal this way: struct GAMJournalEntry { ieStrRef Text; ieDword GameTime; // in game time seconds ieByte Chapter; ieByte unknown09; ieByte Section; ieByte Group; // this is a GemRB extension }; New projectile field, main header: ieDword SparkColor; <-- last field used by the original engine ieDword ExtFlags; <-- special flags (you can see them in dltcep) ieDword StrRef; <-- strref to be printed (once) when the projectile hits ieDword RGB; <-- rgb color modification of target, after the projectile hit (this is a single pulse effect) ieWord ColorSpeed; <-- change of the rgb color ieWord Shake; <-- screen shake when the projectile hit (once) AoE header: ieWord ConeWidth; <--- last used field //these are GemRB specific (from areapro.2da) ieDword APFlags; //areapro.2da flags ieResRef Spread; //areapro.2da first resref ieResRef Secondary; //areapro.2da third resref ieResRef AreaSound; //areapro.2da second sound resource areapro.2da contains these fields for the hardcoded AoE effects (fireball.ids), new projectiles can either use the fireball type as in the original engine, or just override these fields. .spl: the four letter prefix for spells in 0-999 range is 'SPIT'. (IT stands for item, this is planned to be used for upgradable items). This means, an item will have a custom spell possible to attach to it. This would require some additional item entry field, so it is not done yet. (Anyway, resolving spells 0-999 should use that prefix). All modal actions like bardsong, turn, trap finding are customizable spells. We implemented the unused RetreatFrom opcode as the effect of Turn. (It works only in PST somewhat similarly). The Set Sanctuary opcode will not only set the sanctuary field to 1, but it can set that field to any value (based on parameter2, a 0 value will default to 1) - this is to support other overlays 0x12a (pocketplane) will let you run any cutscene stored in the resource field. It of course defaults to cut250a It will always store the party locations. 0x1a (removecurse), if the resource field is set, then it will remove only the specified item. Otherwise works as the original. If parameter1=1, then works like the pst variant. - removes the jumble curse. 0x38 invert alignment - param2 = 0 works as original, = 1 switch only good and evil, 2 switch law/chaotic 0x50 deafness - param1 - amount of mage spell failure (0 defaults to 50), param2 - amount of cleric's failure 0x73 detect alignment - 0,1,2 works as original (gne axis), 3,4,5 detects lnc axis. chaotic - purple, lawful-white, neutral - blue 0x8b displaystring - param2 is an rgb value if nonzero 0xa8 removecreature - if resource is specified, then it will remove a monster named by that resource (so, it won't remove the target, but the monster named by resource) 0xaa damageanimation - param1 if 1, then the target won't groan/recoil, just the fire/ice etc effects play (btw, we improved the number of effects too: but these are detailed by an external 2da: damage.2da) 0xac remove spell - in param2=1 deplete all spells (don't remove from spellbook) param2=2 deplete param1 number of spells Well, i'm sure there are more, but these i found easily Will comment on these later. -Galactygon Link to comment
Galactygon Posted July 18, 2010 Share Posted July 18, 2010 Here are my comments and ideas I'm putting on the table. I've covered the opcodes Avenger told me so far, I will not delve into scripting actions. Some of those opcodes they look very promising. I've also went in to highlight the minor differences between parallel IWD and BGII opcodes up until opcode #232; this is where the effects diverge. From Avenger: The Set Sanctuary opcode will not only set the sanctuary field to 1, but it can set that field to any value (based on parameter2, a 0 value will default to 1) - this is to support other overlays Wouldn't this cause problems of overlays being detected as STAT_SANCTUARY or true sight dispelling overlays (opcode 160)? I've looked for hints on which STAT they set in overlay.2da, but didn't find any. What's the difference between an overlay and a .bam file that is stickied to the character through opcode 215? 0x1a (removecurse), if the resource field is set, then it will remove only the specified item. Otherwise works as the original.If parameter1=1, then works like the pst variant. - removes the jumble curse. The jumble curse part sounds like we won't be seeing much of it in ToB, unless there is an effect called "jumble curse". 0x50 deafness - param1 - amount of mage spell failure (0 defaults to 50), param2 - amount of cleric's failure Never thought of this one. Maybe we could even allow external .effs to be called from the resource key. Like opcode 283 (use EFF as curse), it would react to other opcodes removing this opcode (#81 Cure: Deafness), and allow customizability. #139 displaystring - param2 is an rgb value if nonzero Is DisplayStringHead supported? I like the rgb value, never dreamt of it. #168 removecreature - if resource is specified, then it will remove a monster named by that resource (so, it won't remove the target, but the monster named by resource) Only found out a couple days ago this does not work the way IESDP states. Nice. #172 remove spell - in param2=1 deplete all spells (don't remove from spellbook)param2=2 deplete param1 number of spells Nice. Here are the differences for opcodes 0 - 232 between IWD(2) and BGII. For ease of reading, I've highlighted the differences in bold. #3 (0x003) State: Berserking [3] Parameter #1: IrrelevantParameter #2: Type Description: Applies the berserk effect to the targeted creature(s), as specifed by the 'Type' field. Target will uncontrollably attack enemies if any are in view, and will occasionally attack neutral creatures. Known values for 'Type' are: 0 Default 1 Always Active 2 Blood Rage I'd be wary of implementing type 2, since we would be creating another hardcoded effect. Reading the spell description of blookd rage (in IWD2), it's entirely possible to duplicate the spell using multiple effects except for allowing the stat bonuses to overlap. I think this is why IWD hardcoded entire extension headers into an opcode. I suggest we expand opcode 206 (Protection from spell) instead to have a type that suppresses .spl files instead of outright blocking them. Could solve a lot of problems. Maybe we could have type 2 call an external .eff file in case someone wants to customize this opcode, and still #7 (0x007) Colour: Set character colours by Palette [7] Parameter #1: Gradient NumberParameter #2: Location Description: Alters the colour of the area specified by the 'Location' field, to the colour gradient specified by the 'Gradient Number' field. Known values for 'Location' are: (...) 255 Whole Body Opcodes #8 (Colour: Change by RGB), #9 (Glow Pulse) also have a location of 255 listed as 'whole body' in IWD: TotL, which is absent in BG2:ToB #12 (0x00C) HP: Damage [12] Parameter #1: Damage AmountParameter #2: Type Description: Damages the target by the value specified by the 'Damage Amount' field, with the damage type specified by the 'Type' field. Known values for 'Type' are: 0 Crushing 1 Crushing Set to Value 2 Crushing Set to Percentage 3 Crushing (save for half) 65536 Acid 65537 Acid Set to Value 65538 Acid Set to Percentage 65539 Acid (save for half) 131072 Cold 131073 Cold Set to Value 131074 Cold Set to Percentage 131075 Cold (save for half) 262144 Electricity 262145 Electricity Set to Value 262146 Electricity Set to Percentage 262147 Electricity (save for half) 524288 Fire 524289 Fire Set to Value 524290 Fire Set to Percentage 524291 Fire (save for half) 1048576 Piercing 1048577 Piercing Set to Value 1048578 Piercing Set to Percentage 1048579 Piercing (save for half) 2097152 Poison 2097153 Poison Set to Value 2097154 Poison Set to Percentage 2097155 Poison (save for half) 4194304 Magic 4194305 Magic Set to Value 4194306 Magic Set to Percentage 4194307 Magic (save for half) 8388608 Missile 8388609 Missile Set to Value 8388610 Missile Set to Percentage 8388611 Missile (save for half) 16777216 Slashing 16777217 Slashing Set to Value 16777218 Slashing Set to Percentage 16777218 Slashing (save for half) 33554432 Magic Fire 33554433 Magic Fire Set to Value 33554434 Magic Fire Set to Percentage 33554435 Magic Fire (save for half) 67108864 Magic Cold (?) 67108865 Magic Cold (?) Set to Value 67108866 Magic Cold (?) Set to Value 67108867 Magic Cold (?) (save for half) 134217728 Stunning 134217729 Stunning Set to Value 134217730 Stunning Set to Percentage 134217731 Stunning (save for half) 268435456 Soul Eater (?) 268435457 Soul Eater (?) Set to Value 268435458 Soul Eater (?) Set to Percentage 268435459 Soul Eater (?) (save for half) 1073741824 Disease 1073741825 Disease Set to Value 1073741825 Disease Set to Percentage 1073741827 Disease (save for half) The advantage of save for half damages is cosmetic: The damage is handled in one effect, and damage strings are displayed once - the game message window isn't spammed with 2 damage texts, so it's easier to keep track of what happened during combat. Does GemRB fix the crash of magic fire and cold? #22 (0x016) Stat: Luck Modifier [22] Parameter #1: Statistic ModifierParameter #2: Type Description: Applies the modifier value specified by the 'Statistic Modifier' field in the style specified by the 'Type' field. The effect does not set STATE_LUCK. Known values for 'Type' are: 0 Cumulative Modifier -> Luck = Luck + 'Statistic Modifier' value 1 Lucky Streak 2 Fortunes Favorite (perfect rolls) I don't know types 1 and 2 do, my guess (for #1) is they duplicated an entire extended header in an opcode. #24 (0x018) State: Horror [24] Parameter #1: IrrelevantParameter #2: Type Description: Applies the horror effect to the targeted creature(s), in the style specified by the 'Type' field. Known values for 'Type' are: 0 Normal 1 Harpy Wail They probabbly duplicated an entire extended header in an opcode. Only advantage that I can think of is it reacts to #161 Cure: Fear, and can be blocked by #101. I suggest introducing a new type that makes use of the resource key by calling an external effect (like the existing BGII curse opcode 283). #25 (0x019) State: Poison [25] Parameter #1: Damage AmountParameter #2: Type Description: Damages the target by the 'Damage Amount' value, in the style specified by the 'Type' field. Known values for 'Type' are: 0 1 Inflict 'Damage Amount' per second halting at value controlled by 'Damage Amount' (pattern unknown) 2 Inflict 'Damage Amount' per second 3 Inflict 1 Damage per 'Damage Amount' seconds 4 Inflict 'Damage Amount' per round 5 Crash 6 Snakebite 8 Envenomed Weapon Again, they probabbly duplicated an entire extended header in an opcode. Clear advantage is that it reacts to cure poison, and opcode 101. I'm suggesting introducing a new type that makes use of the resource key by calling an external effect (like the existing BGII opcode 283). #42 (0x02A) Spell: Wizard Spell Slots Modifier [42] Parameter #1: Slot Amount ModifierParameter #2: Spell Level Description: Alters the number of wizard spell slots available to the targeted creature(s), as specified by the 'Slot Amount Modifier' field, at the level specified by the 'Spell Level' field. Known values for 'Spell Level' are: 0 Double spells 1 Level 1 2 Level 2 4 Level 3 8 Level 4 16 Level 5 32 Level 6 64 Level 7 128 Level 8 256 Level 9 512 Double spells For a 'Spell Level' of 0, the amount of spell slots is doubled for the level specified by the 'Slot Amount Modifier' value and all levels below. For a 'Spell Level' of 512, the amount of spell slots is doubled for the level(s) specified by the 'Slot Amount Modifier' field. The target creature(s) must have at least 1 slot at the selected level to have their slot count changed. If the resultant slot count is negative, the creature is given 12 slots. 'Statistic Modifier' can be positive or negative. Implemented recently by FlameWing. Maybe we could introduce type 1024 that sets the slots of a particular spell level to param3 slots. Can only be used in external .effs. #44 (0x02C) Stat: Strength Modifier [44] Parameter #1: Statistic ModifierParameter #2: Type Description: Applies the modifier value specified by the 'Statistic Modifier' field in the style specified by the 'Type' field. Known values for 'Type' are: 0 Cumulative Modifier -> Strength = Strength + 'Statistic Modifier' value 1 Flat Value Modifier -> Strength = 'Statistic Modifier' value 2 Percentage Modifier -> Strength = (Charisma * 'Statistic Modifier' value) / 100 3 Strength Spell ('Statistic Modifier' should be set to 0) Negative values for 'Statistic Modifier' act as follows for the 'Type' modes: 0 Strength = Strength - 'Statistic Modifier' value 1 Strength = 25 2 Strength = 25 Commented on this at SHS. Again, they duplicated an extended header in a single opcode. I suggest we make use of all 4 bytes for stat-enhancing effects like these: 1 byte for the "Type", another for whether to ignore partial 18/... STR values, and a third byte could be sort of an "ID" value. Effects of the same "ID" value would overlap. We can use the last bit to specify the maximum (if parameter1 > 0) or minimum (if parameter1 < 0) value which beyond the strength modification does not go. The reason I'm for introducing "ID" values is customizability. Someone might want his own effects to stack. Existing effects would remain unchanged, there would be no backwards-compatibility issues. Changing the opcode to be fundamentally non-cumulative would raise other problems: negative strength modifiers wouldn't do anything, and some effects are designed to be cumulative with other effects but not with themselves. #45 (0x02D) State: Stun [45] Parameter #1: IrrelevantParameter #2: Type Description: Stuns the targeted creature(s). Known values for 'Type' are: 0 Normal 1 Unstun on Damage 2 Power Word Stun Type 1 is interesting, maybe you could also change the unconscioussness opcode to something like this, so that we could still have the option of sleep-without-awaken-on-hit? #50 (0x032) Colour: Glow by RGB (Brief), #51 (0x033) Colour: Strong/Dark by RGB [51], #52 (0x034) Colour: Very Bright by RGB [52] Location may be set to 255, the whole body. #62 (0x03E) Spell: Priest Spell Slots Modifier [62] As opcode #42 (Wizard Spell Slots Modifier), code implemented by FlameWIng. #66 (0x042) Graphics: Transparency Fade [66] Parameter #1: Fade AmountParameter #2: Type Description: Fades the targeted creature(s) by the value in the amount specified by the 'Fade Amount' field. Known values for 'Fade Amount' are: 1 Fully visible .. 255 Almost invisible Known values for 'Type' are: 0 Default 1 Fade In 2 Fade Out Fun to watch in IWD, it would be good to see this in BGII, maybe with a setting to adjust the speed at which the fade happens. #73 (0x049) Damage Mod Parameter #1: Damage ModifierParameter #2: Type Description: Inflicts a percentage extra damage (set by the 'Damage Modifier' parameter) of the type specified by the 'Type' parameter. Known values for 'Type' are: 0 Standard 1 Fire 2 Cold 3 Electricity 4 Acid 5 Magic 6 Poison 7 Slashing 8 Piercing 9 Crushing 10 Missile Note. 'Type' 0 causes a flat damage increase, rather than a percentage. This effect is completely different from what we see in BGII: ToB. This opcode could be handled like #12 (damage), with each byte of parameter2 being used. #78 (0x04E) State: Disease [78] Parameter #1: DamageParameter #2: Type Description: Set the Damage parameter as the amount of damage, and the Disease Type parameter as how the disease functions. Known values for 'Type' are: 1 Hit Points per round 2 Hit Points per Second 3 Seconds per Hit Points 4 Strength Penalty 5 Dexterity Penalty 6 Constitution Penalty 7 Intelligence Penalty 8 Wisdom Penalty 9 Charisma Penalty 10 Slow Effect 11 Mold Touch 13 Contagion 'Damage' can be positive (penalty) or negative (bonus). Permanent timing modes require a duration for this effect to work. Note: Paladins are immune to this opcode. See my comments on poison. #124 (0x07C) Spell Effect: Teleport (Dimension Door) [124] Parameter #1: IrrelevantParameter #2: Irrelevant Description: Teleports the targeted creature(s) in the style specified by the 'Type' field. Known values for 'Type' are: 0 Default 1 Source to Target 2 Return to Saved Location 3 Exchanged Source and Target #206 (0x0CE) Spell Effect: Immunity Spell [206] Parameter #1: IrrelevantParameter #2: Type Description: The creature type specified by the 'Type' field becomes immune to the spell specified by the resource key. Known values for 'Type' are: 0 Default 1 Undead 2 Not Undead 3 Fire Using/Dwelling 4 Not Fire Using/Dwelling 5 Humanoid 6 Not Humanoid 7 Animal 8 Not Animal 9 Elemental 10 Not Elemental 11 Fungus 12 Not Fungus 13 Huge Creature 14 Not Huge Creature 15 Elf 16 Not Elf 17 Umber Hulk 18 Not Umber Hulk 19 Half-Elf 20 Not Half-Elf 21 Humanoid or Animal 22 Not Humanoid or Animal 23 Blind 24 Not Blind ... It looks like GemRB externalizes the 'Type' to splprot.2da. It's possible in BGII to duplicate this by nesting opcode 206 into .eff files and placing them at the start of each extended header with mass patching. I suggest we do something different for BGII by externalizing opcode 177 (Use .EFF File) into a .2da table that contain script blocks with each row getting a different type and the script block being executed sideways. ie it would look something like this: Type Condition#1 Condition#2 ... ... Condition#x 2 Allegiance(PRE_TARGET,PARAMETER_1) *** *** // Already exists in-game 3 General(PRE_TARGET,PARAMETER_1) *** *** // Already exists in-game ... 13 OR(2) AreaType(CITY) AreaType(FOREST) // Something I made up 14 !Gemeral(ORIGINAL_CASTER,PARAMETER_1) State(Myself,STATE_BLINDED) Range("SUJON",15) // Something I made up ... In other words, we could mimick script blocks in extended headers. Highly customizable, and could solve a lot of the problems in the IE. We could duplicate any of the Power Word opcodes with conditions like HPLT(PRE_TARGET,x), or have an effect that fires only if a quest is completed an a global variable is set. Avenger/Lynx: could you comment on these? Maybe we are thinking the same thing, or the same features might be implemented in a different way. Or maybe there are better solutions and ideas than what I put forth. -Galactygon Link to comment
lynx Posted July 18, 2010 Share Posted July 18, 2010 GemRB shouldn't have any problem with magic cold/fire. If you find any, let me know. DisplayStringHead is currently only implemented enough to show the simple overhead text like in most games, but not the fancy message window replacement as in pst. Damage mod is implemented in both variants. Save-for-half damage types are not handled so nicely (double messages). "512 Double spells" is also done and I'm sure much of the rest. Extension is always possible, but our first goal is to make the originals playable. Also keep in mind that IESDP is not absolutely correct in many places. Link to comment
Avenger Posted July 18, 2010 Share Posted July 18, 2010 There is a floattext opcode in the IWD effect set. If you implement it, better use a different opcode (if the opcode number is give, gemrb just needs a textfile to be adjusted to assign the number to the effect). The deafness opcode is only to change casting failure. Of course you can call a special effect or such, but you don't need this opcode for that. Keep it simple We implement the iwd2 specific quirks. (for example: dex - cat's grace - and bull's strength gives random boost based on class). Using: clssplab.2da DEX STR UNUSED 6 8 MAGE 6 4 FIGHTER 6 8 CLERIC 4 6 THIEF 8 6 BARD 8 6 PALADIN 6 8 FIGHTER_MAGE 6 8 FIGHTER_CLERIC 6 8 FIGHTER_THIEF 8 8 FIGHTER_MAGE_THIEF 8 8 DRUID 4 6 RANGER 6 8 MAGE_THIEF 8 6 CLERIC_MAGE 6 6 CLERIC_THIEF 8 6 FIGHTER_DRUID 6 8 FIGHTER_MAGE_CLERIC 6 8 CLERIC_RANGER 6 8 The sanctuary stuff is for handling the hardcoded overlays. #215 is available, but for regular overlays, you did not need to supply a resref. As you see, lots of resources are not existing in bg2, those are from IWD, to support crossovers. Our overlay 2da for ToB looks like this: VVC UNDER SANCTUARY SANCTRY 0 ENTANGLE SPENTACI 0 SPELLTRAP SPMAGGLO 0 SHIELDGLOBE SPSHIELD 0 GREASE GREASED 1 WEB WEBENTD 1 MINORGLOBE MINORGLB 0 GLOBE GOINVUC 0 FLAMESHROUD SOFLAMC 0 ANTIMAGIC AMSHELC 0 RESILIENT ORSPHEC 0 PROTFROMMISS PFNMISC 0 CLOAKOFFEAR COFEARC 0 ENTROPY ESHIELC 0 FIREAURA FIAURAC 0 FROSTAURA FRAURAC 0 INSECT IPLAGUC 0 STORMSHELL SSHELLC 0 LATHANDER1 SOLATC1 0 LATHANDER2 SOLATC2 1 GLATHANDER1 GSOLAC1 0 GLATHANDER2 GSOLAC2 1 SEVENEYES1 SEYESC1 0 SEVENEYES2 SEYESC2 1 BOUNCE SPTURNI2 1 BOUNCE2 SPTURNI 1 FIRESHIELD1 FSHIRC1 0 FIRESHIELD2 FSHIRC2 1 ICESHIELD1 FSHIBC1 0 ICESHIELD2 FSHIBC2 1 TORTOISE TSHELLC 0 DEATHARMOR DARMORC 0 Link to comment
Galactygon Posted July 19, 2010 Share Posted July 19, 2010 We implemented the unused RetreatFrom opcode as the effect of Turn. (It works only in PST somewhat similarly). Backtracking a bit, I've opened TURN.spl, and noticed parameter2 was set to 4. What role do they have? I figure turn undead works at the same effectiveness whether you are turning 1 undead or 10. IIRC it works the same way in BGII. DisplayStringHead is currently only implemented enough to show the simple overhead text like in most games, but not the fancy message window replacement as in pst. I was wondering whether it is possible to display a strreff on the head of a .cre in BGII through an opcode. Damage mod is implemented in both variants. Save-for-half damage types are not handled so nicely (double messages). Shame. IWD(2) can handle it. I mimick this by setting off 3 effects in quick succession: damage effect (with a saving throw), opcode 101 protection from opcode (with a saving throw), and another damage effect (no saving throw). If the saving throw is failed, the first damage effect fires, and the succeeding "protect from opcode" effect protects the .cre from the last damage effect. A duration value of 0 for an effect works while the game executes the rest of the effects in the extended header. Is it possible to hardcode such behaviour for "save for half"-damages?- There is a floattext opcode in the IWD effect set. If you implement it, better use a different opcode (if the opcode number is give, gemrb just needs a textfile to be adjusted to assign the number to the effect). Unfortunately, it is taken up by a different effect in BGII: Use EFF File (Cursed). I would rather support expanding the existing display string opcode. If 3 bits of param2 are taken up by the RGB value (and param1 is the strref), there is still a vacant 4th bit of param2, and parameters 3 and 4 (for .eff files). The deafness opcode is only to change casting failure. Of course you can call a special effect or such, but you don't need this opcode for that. Keep it simple I've only started to look at GemRB, I don't know how it works. I'm rationalizing from a just-BGII:ToB point of view, without introducing new types of scripting. I'll explain my reasoning behind nested .effs through an example: Say someone wishes to write a mod that causes deafened characters to hiccup while deafened, assuming an opcode for hiccuping exists. The modder patches every single .spl and .itm in the game by inserting a hiccuping opcode next to each deafness opcode with identical saving throws, durations, etc. In order to have a "Cure Deafness" effect also remove the hiccuping, the modder will also have to patch each deafness removing .spl and .itm to have a remove hiccuping effect as well. But now hiccuping coming from other sources than deafness are removed as well by the remove deafness spell or item. I got this idea from the existing Opcode 283 "Use EFF File (Cursed) [283]", which reacts to remove curse. This allows us to completely customize curses. Another place where nested .effs can have their use are decrementing effects (spell deflection, spell turning, spell trap, stoneskin). Since these .effs are inherintly non-cumulative, we could have the same opcode reapplied several times in a single extended header each calling for a different embedded effect. We could then customize what overlay it plays, and more important, which stats they set. Less problems for DetectableSpells. We implement the iwd2 specific quirks. (for example: dex - cat's grace - and bull's strength gives random boost based on class). Using: clssplab.2da This has it's advantages in an IWD-point of view, where existing effects call on Cat's Grace and Bull's Strength. From a ToB point of view, I don't think it would add much to the engine. Backtracking to my "ID"s idea I suggest we make use of all 4 bytes for stat-enhancing effects like these: 1 byte for the "Type", another for whether to ignore partial 18/... STR values, and a third byte could be sort of an "ID" value. Effects of the same "ID" value would overlap. We can use the last bit to specify the maximum (if parameter1 > 0) or minimum (if parameter1 < 0) value which beyond the strength modification does not go. The reason I'm for introducing "ID" values is customizability. Someone might want his own effects to stack. Existing effects would remain unchanged, there would be no backwards-compatibility issues. Changing the opcode to be fundamentally non-cumulative would raise other problems: negative strength modifiers wouldn't do anything, and some effects are designed to be cumulative with other effects but not with themselves. The sanctuary stuff is for handling the hardcoded overlays.#215 is available, but for regular overlays, you did not need to supply a resref. As you see, lots of resources are not existing in bg2, those are from IWD, to support crossovers. Does it still set STAT_SANCTUARY, and react to opcode "Remove Sanctuary [160]" if some other overlay plays instead of sanctuary? I've noticed that hardcoded BG1 overlays (minor globe, normal missiles, sanctuary) disappear when the creature becomes invisible, and continue to play during timestop. This is not true for the hardcoded BG2 overlays (turning, deflection). How does GemRB handle these? Is it possible to set some parameters in opcode 215 (Play 3D) to make this happen, or will I have to append overlay 2da? Another question: if .vvc files can handle what plays in front of, or beind characters, what use does VVC UNDER have in overlay 2da? -Galactygon Link to comment
Avenger Posted July 20, 2010 Share Posted July 20, 2010 Floattext: Obviously, you can add new opcodes to the ToBEX engine. For GemRB, it is just adding a new line to effects.ids: <your opcode> FloatText Transparency: Yes, we implemented the fade in/out stuff (it is available in bg2) Save for half: Done, we support the pst version (resref field decides) too. As a rule of thumb: If an iwd/pst effect is a superset of the bg version, we implemented the effect in the bg version. If it was slightly different, we do it via options or implement both ways (like all our bg2 spells automatically handle the iwd spell states). If it was significantly different, we added a new opcode. Deafness: Well, it would be better to add some entirely new mechanism for this. Improving the apply spell on condition opcode seems the solution. Or implementing the iwd style targeting (their alternative for ids targeting), but externalized. You talk about a single opcode, that would be more complex, and it is only one opcode. You would need to change another, if you want to add extra perks to blindness. VVC: IWD has no vvc, that list is almost identical to how it orders the overlays internally. We keep the same in bg2 only to make crossovers easier. Sanctuary: Yes, atm, our cure sanctuary effect removes any of the sanctuary effects (we'll change this). It is not a bug for any of the original games, but it would be buggy if someone would use the new options. The solution would be to have the cure remove only effects that use the same param2. stat modifiers: I don't really understand your point. We cannot stray from iwd as it is a superset of bg (except if we implement both opcodes, which i don't really want). But as long as you don't add any param2 that overlaps the iwd versions, we can stay compatible No one said we need to have the same opcodes/params, just avoiding clashes is good enough. If you split param2 into two words, and use the high field for non stacking, etc. then i guess, we can work with that. Poison: Yes, the additional options are not really useful (bg2 does this better with 'apply spell repeatedly') Dimension door: I don't agree with you. Those new options are a cool addition. Spell slot bonuses: Yes, new bits are fine. Just make sure both opcodes (mage/cleric) use the same bits. If a bit doesn't make sense (or don't need to implement), in one version, leave it free. Link to comment
Avenger Posted July 20, 2010 Share Posted July 20, 2010 My splprot code is not working for all cases and by no means generic enough. Its advantage is that 4 numbers can describe a condition, instead of a list of 1-n. It is admittedly less readable than your trigger list, but i don't think i would need the trigger list just to reimplement IWD. At this point, the goal of gemrb is to reimplement the originals with possible small additions/bugfixes. No new big system is added (it would just hinder the main goal). I agree that cast spell on condition/resist spell on condition stuff is suboptimal in any of the original engines, their programmers seem to struggle to find a generic way. (In iwd1 they failed miserably with the lots of hardcoding). But to fulfill the goal, we must first reimplement all their hacks before we could add a new mechanism. In other words, i like your idea, but i don't want to implement it first I just ask you that if you add something to ToBEX, make it so it remains compatible with the original engines (a tob game or tob mod would still be playable on ToBEX, and that you don't add options to existing opcodes that would clash with iwd/pst). If you reimplement an iwd/pst feature in place it is good. Also, if you add some new option, because we cannot stray from iwd/pst either. Any GemRB-only options are alterable if there is a better idea and the change doesn't involve a large heap of code. Link to comment
Galactygon Posted July 20, 2010 Share Posted July 20, 2010 Floattext:Obviously, you can add new opcodes to the ToBEX engine. For GemRB, it is just adding a new line to effects.ids: <your opcode> FloatText I've opened the GemRB effects.ids in the override/bg2 directory, and here are the differences I've found: Opcode 23 (was Cure: Horror, now MoraleModifier) opcode 110 (was Retreat From, we now know it turns undead in GemRB, but this isn't documented in the effects.ids as TurnUndead) - How does this work? opcode 245 (was Check for Berserk, now CheckForBerserkModifier) opcode 425 ControlUndead2 Here are the opcodes opcode 61 - AlchemyModifier opcode 114 - Dither opcode 118 - Show Creatures opcode 121 - Visual Animation Effect opcode 149 - Identify opcode 260 - Crash opcode 291 - Existance Delay Modier (we don't know what it is, but according to the IESDP it sets stat 184) opcode 312 - Crash everything after and including opcode 318 Are any of these slots taken by GemRB? I haven't found any hints for the floattext opcode in the effects.ids for bg2; I figure GemRB can handle multiple effects.ids files, since can call an effect from another game. Transparency:Yes, we implemented the fade in/out stuff (it is available in bg2) Cool. Save for half:Done, we support the pst version (resref field decides) too. Nice. Implementing the PST part into BG2:ToB would clash with existing effects, since they do not have "NEG" set in the resource key. As a rule of thumb:If an iwd/pst effect is a superset of the bg version, we implemented the effect in the bg version. If it was slightly different, we do it via options or implement both ways (like all our bg2 spells automatically handle the iwd spell states). If it was significantly different, we added a new opcode. This makes it easier for us to start somewhere. We need a masterlist - sort of like an IESDP for GemRB. Deafness:Well, it would be better to add some entirely new mechanism for this. Improving the apply spell on condition opcode seems the solution. Or implementing the iwd style targeting (their alternative for ids targeting), but externalized. You talk about a single opcode, that would be more complex, and it is only one opcode. You would need to change another, if you want to add extra perks to blindness. My suggestion is to have one opcode do 2 things - a.) apply the effects and stats to the .cre, and b.) apply an external .eff in the resource key. Our solutions would be compatible with each other and with existing effects in-game. VVC:IWD has no vvc, that list is almost identical to how it orders the overlays internally. We keep the same in bg2 only to make crossovers easier. Ok. Sanctuary:Yes, atm, our cure sanctuary effect removes any of the sanctuary effects (we'll change this). It is not a bug for any of the original games, but it would be buggy if someone would use the new options. The solution would be to have the cure remove only effects that use the same param2. Wouldn't it be easier to use one of the blank effects? Even IWD(2) calls overlays and handles sanctuary through seperate effects. stat modifiers:I don't really understand your point. We cannot stray from iwd as it is a superset of bg (except if we implement both opcodes, which i don't really want). But as long as you don't add any param2 that overlaps the iwd versions, we can stay compatible No one said we need to have the same opcodes/params, just avoiding clashes is good enough. If you split param2 into two words, and use the high field for non stacking, etc. then i guess, we can work with that. Agreed. Poison:Yes, the additional options are not really useful (bg2 does this better with 'apply spell repeatedly') The only problem is, Cure poison does not cure 'apply spell repeatedly'. Which takes us back to deafness. Dimension door:I don't agree with you. Those new options are a cool addition. I never had anything against those, I agree they make a cool addition. In other words, i like your idea, but i don't want to implement it first Thanks, we'll see what Ascension64 says. I just ask you that if you add something to ToBEX, make it so it remains compatible with the original engines (a tob game or tob mod would still be playable on ToBEX, and that you don't add options to existing opcodes that would clash with iwd/pst). Ascension64 has the final word; unfortunately I don't have the coding background to hack the engine. -Galactygon Link to comment
Avenger Posted July 20, 2010 Share Posted July 20, 2010 I've opened the GemRB effects.ids in the override/bg2 directory, and here are the differences I've found:Opcode 23 (was Cure: Horror, now MoraleModifier) opcode 110 (was Retreat From, we now know it turns undead in GemRB, but this isn't documented in the effects.ids as TurnUndead) - How does this work? opcode 245 (was Check for Berserk, now CheckForBerserkModifier) opcode 425 ControlUndead2 Here are the opcodes opcode 61 - AlchemyModifier opcode 114 - Dither opcode 118 - Show Creatures opcode 121 - Visual Animation Effect opcode 149 - Identify opcode 260 - Crash opcode 291 - Existance Delay Modier (we don't know what it is, but according to the IESDP it sets stat 184) opcode 312 - Crash everything after and including opcode 318 Are any of these slots taken by GemRB? I haven't found any hints for the floattext opcode in the effects.ids for bg2; I figure GemRB can handle multiple effects.ids files, since can call an effect from another game. Alchemy modifier is iwd2 specific (modifies the alchemy skill). Just for the sake of easier crossovers, I added this effect to the bg2 set, it modifies the alchemy skill stat. (The stats are a bit static in gemrb, not as flexible as scripting stuff or effects). Besides, alchemy is cool. It would be interesting to implement it in bg2. (-5) Dither - it is not implemented in any engine, (gemrb has it as a placeholder), i guess it was to make the actors rendered with the dithered effect (you can see this when they are half covered by walls). It would be easy to implement, but nothing ties us to use this opcode number. (-1) Show creatures - Similar to dither, but i don't even know how to implement this (0) Visual animation effect - ditto (0) Identify - We actually implement this by setting the identify stat to 1. The original engines either don't use this, or do it in a special way. As it may be used by the original engine. (-6) 260 crash - use this as you want, i doubt it is used by bg2, we don't use it (5) 291 existance delay modifier - it is a perfectly working opcode. I think 'existance' means the idle verbal constants (existance1-5), it might set the delay between them. Ascension64 just fixed something about them, i vote we keep it. (-6) 312 crash (immune to sequester) - this opcode is actually revivable. I don't know what exactly it does. It just lacks a proper constructor. Ask Ascension64/Taimon/DevSin. (-3) 318 and above (including the turnundead effect) - fine to me. I'm unsure why we use 425 controlundead2 instead of just overwriting the dummy retreatfrom slot. (this wasn't even me, i believe). My plan was to use it as i didn't want to add new opcodes originally. opcode 245 - it modifies the 'check for berserk' stat. So it is the same stuff. We don't even use the modifier protocol (add/set/percent), just set it (but if you want to change it as 0xa6, we can do it easily). opcode 23 - this is actually a screwup in bg1/bg2. BG2 seems to have been hacked to become a dumb set morale to 10 opcode. In bg1 and other games it is different. I would probably check how bg2 uses it. And try to make it so that all original games work with the same code. I haven't decided what to do with this. Save for half:Done, we support the pst version (resref field decides) too. Nice. Implementing the PST part into BG2:ToB would clash with existing effects, since they do not have "NEG" set in the resource key. I guess, you meant, they wouldn't clash Actually there is an option: GF_SAVE_FOR_HALF (this selects between the two save for half implementations). So, i have to retract my statement that both methods would work in the same game. As a rule of thumb:If an iwd/pst effect is a superset of the bg version, we implemented the effect in the bg version. If it was slightly different, we do it via options or implement both ways (like all our bg2 spells automatically handle the iwd spell states). If it was significantly different, we added a new opcode. This makes it easier for us to start somewhere. We need a masterlist - sort of like an IESDP for GemRB. Yep. I would actually have this in the regular IESDP. But it could be added to the gemrb wiki too. I just thought all this stuff is still subject to change, so it is more up to date if i just check the source code. I also got more important things to do and no one asked me before If someone does the bulk job and builds the list from scratch, i volunteer to fix problems in the documentation. (Actually, this might mean i change the code to fit the specification in some cases). Sanctuary:Yes, atm, our cure sanctuary effect removes any of the sanctuary effects (we'll change this). It is not a bug for any of the original games, but it would be buggy if someone would use the new options. The solution would be to have the cure remove only effects that use the same param2. Wouldn't it be easier to use one of the blank effects? Even IWD(2) calls overlays and handles sanctuary through seperate effects. Yes, maybe. In this case, you just have to worry about ToB anyway. It is my problem to keep GemRB compatible with ToB (and ToBEx), and the IWD branch. If this cannot be maintained, i will simply revert this opcode to behave exactly like in ToB. Sanctuary was chosen only because i use the sanctuary stat for all overlays. (IWD has no such separate stat). Poison:Yes, the additional options are not really useful (bg2 does this better with 'apply spell repeatedly') The only problem is, Cure poison does not cure 'apply spell repeatedly'. Which takes us back to deafness. You can always make it so. And yes, it is the same as deafness. Either you code entire spells in an effect option or use a generic 'apply spell repeatedly'. I don't see a third option. IWD2 reimplemented a lot of IWD/HOW hardcodedness using various apply spell opcodes (they got a lot of them, and they are cool). In many cases, we actually use a separate spell that is applied when an opcode option is set. And in one case, we hardcode the same crap (seven eyes), as IWD. Though, it could be more flexible, i just couldn't force myself to externalize everything. You shouldn't worry about this yet. These things don't exist in ToB, it would be better to externalize ToB stuff first and possibly implement 'easy' stuff from iwd. I didn't even know Ascension64 would care too much about adding new features to ToBEX Dimension door:I don't agree with you. Those new options are a cool addition. I never had anything against those, I agree they make a cool addition. Ahh, i thought you meant you don't like the options because it is the same arbitrary 'whole spells hardcoded in an opcode' stuff. In poison, this is actually true. Link to comment
Galactygon Posted July 21, 2010 Share Posted July 21, 2010 Show creatures - Similar to dither, but i don't even know how to implement this (0)Visual animation effect - ditto (0) These two are the same? Yes, maybe. In this case, you just have to worry about ToB anyway. It is my problem to keep GemRB compatible with ToB (and ToBEx), and the IWD branch. If this cannot be maintained, i will simply revert this opcode to behave exactly like in ToB. Sanctuary was chosen only because i use the sanctuary stat for all overlays. (IWD has no such separate stat). We'd have to agree which opcode to use. Resummarizing, overlays are different from .vvcs "stickied" by opcode 215 in the following ways: a.) they play a .bam file rather than a .vvc file - their rendering/blending is harcoded. b.) they do not play on creatures out of sight from the party (very important IMO) c.) they change the RGB of the entire creature to a set value d.) they do not pause when caster is in a timestop e.) they set some sort of stat while they are active None of these apply to the hardcoded BG2 overlays spell turning and spell deflection/trap. (How) Does GemRB solve these questions? You can always make it so. And yes, it is the same as deafness. Either you code entire spells in an effect option or use a generic 'apply spell repeatedly'. I don't see a third option. How would you remove the "apply spell repeatedly" from single .spl or .itm source? IWD2 reimplemented a lot of IWD/HOW hardcodedness using various apply spell opcodes (they got a lot of them, and they are cool).In many cases, we actually use a separate spell that is applied when an opcode option is set. And in one case, we hardcode the same crap (seven eyes), as IWD. Though, it could be more flexible, i just couldn't force myself to externalize everything. You shouldn't worry about this yet. These things don't exist in ToB, it would be better to externalize ToB stuff first and possibly implement 'easy' stuff from iwd. I didn't even know Ascension64 would care too much about adding new features to ToBEX You could mimick this by using BGII's opcode 146 "cast spell on creature". The two shortcomings I can think of right now is: a.) there is no "dispel by resource" opcode, so you have to fiddle with sectypes and b.) if a non-creature (like a trap) fires a .spl with this opcode, the game CTDs. -Galactygon Link to comment
Avenger Posted July 21, 2010 Share Posted July 21, 2010 They got the same category: they don't work, i don't implement them, but they could be implemented. There are worse and better candidates for opcode recycling. GemRB doesn't care much about whether playing a bam or vvc (similarly to the ToB engine). If it doesn't find a VVC, it loads a BAM. It will still convert the BAM to a VVC internally, but it needs hints. One of these hints are the play under/over stuff. If there is a VVC, its settings will overwrite the behaviour. If there is a sound effect or blending accompanied to a BAM, i 'can' supply a VVC for it. There are vvcs made by me for: minorglobe/sanctuary/shield/entangle (and in iwd: sanctuary). c.) they change the RGB of the entire creature to a set value The palette color lock is coded into the effect. b.) they do not play on creatures out of sight from the party (very important IMO) I don't draw anything when not seen, i think d.) they do not pause when caster is in a timestop I don't pause any overlay (be it hardcoded or 0x215) because of timestop. I don't think i should, i didn't even notice this quirk. e.) they set some sort of stat while they are active The stat setting is in the opcode. >How would you remove the "apply spell repeatedly" from single .spl or .itm source? >a.) there is no "dispel by resource" opcode, Oh, but there IS (0xfe). Hmm, Asc should write it, but it exists in IWD/GemRB. You can remove an effect coming from a specific source. ASR is not different from other opcodes. Link to comment
Galactygon Posted July 21, 2010 Share Posted July 21, 2010 c.) they change the RGB of the entire creature to a set valueThe palette color lock is coded into the effect. If someone wants to come along and change the colouring of an overlay or introduce a new one, how could (s)he do so? I've looked for RGB hints in the overlay.2da, and found none. b.) they do not play on creatures out of sight from the party (very important IMO)I don't draw anything when not seen, i think It would be nice to see this in BGII. If I want any .bam to never play on invisible non-allied creatures, how could I achieve that in GemRB? I don't pause any overlay (be it hardcoded or 0x215) because of timestop. I don't think i should, i didn't even notice this quirk. I don't understand this. Is this opcode 215? e.) they set some sort of stat while they are activeThe stat setting is in the opcode. This means we would still be setting a stat in a seperate effect in the extended header? >How would you remove the "apply spell repeatedly" from single .spl or .itm source?>a.) there is no "dispel by resource" opcode, Oh, but there IS (0x0fe). Hmm, Asc should write it, but it exists in IWD/GemRB. You can remove an effect coming from a specific source. ASR is not different from other opcodes. The IESDP lists 0x0fe as "Spell Effect: Remove Map Marker" in BGII. I don't think we'd be overwriting this opcode. What solution does GemRB use that is possible to implement in ToBEX? -Galactygon Link to comment
Recommended Posts
Archived
This topic is now archived and is closed to further replies.