marchitek

So, you would be surprised hearing that people write books on this. From my experience bug is usually difference between application behavior and specification or difference between application behavior and expected application behavior (I guess this fits better here since there is no specification to refer to). I have a feeling that QA team was aware of this duplication when game has original realese and this wasn't fixed for purpose. It could be because this wasn't consider a bug (read: it was consider as expected behavior or it was right with specification that was available back then) or... And here goes the best part. In engineering you don't fix all bugs. You don't rebuild whole thing because of minor flaw. Ofc the question is who should decide about what is worth to fix (usually it is investor). In our case it seems to be "community". And here we go again... TLDR: I think this is far more complicated then you states.

Ah yeah, for sure "game breaking" requires further clarification. You know, it's impossible to be 100% strict with language that we have. So, I hope you understand what me and others have in mind here and why "item duplication fix" don't exactly fit (for us) into this category. Maybe someone else explain it with better wording.

I would say arguments that points to realism are useless here. One would need first to show that making game more realistic is making game better, which is IMHO matter of taste (I would strongly disagree). Anyway, answer to all questions could be "magic". I'm not fan of this change because it is small benefit (description change) comparing to impact of change (changing resrefs of items). But on the other hand if BD already started doing this, then it would be making game more consistent, what is good. On the third hand I like this approach: Maybe ti could be good rule of thumb: what is breaking game -> mandatory fix, what is not breaking but probably developer intention -> optional fix.

Ok. I would know for the future that it is always equivalent. This was kind of oblivious to me that this action need some creature to be "active creature" to work properly, that is why I thought "The action only works from a creature script." brings some new information.

IESDP says: (link) This is not true in BGEE v2.6. where it works from global scripts when used with ActionOverride(). It is also used in game cutscenes scripts. --- I made similar post earlier, but it seems to be gone because of server problems.

I recently saw how gamepad is supported on console version of BGEE and it seems really cool, at least for exploration of areas. Normally exploring is like "move viewport -> click -> move viewport -> click", it's a bit tedious. I usually use WASD to move viewport to reduce cursor trips to screen edge back and forth, but it's still two actions, when in fact only one is needed. Is it something that would allow on PC version something similar to gamepad experience for exploration? So viewport would follow party when not in combat or anything like it? Maybe it can be enabled with some set of configuration or some mod?

Exactly. I wasn't even dreaming about making this generation during gameplay, but I guess installation time generation is totally fine. Interesting idea with ranom treasures table, I didn't know that it is possible to add new one. One drawback of this approach is that you need to generate every possible combination during installation (and it should be a lot to have actual diversity) . I was thinking about something like scanning CRE files and containers, checking what need to be generated and then generate and assign. So in fact even more "installation time".

Thank you all for the feedback! I'm currently not planning to add this. One thing is that there are some technical pitfalls here and there to extend it like this and I'm not quite motivated to face them right now. Another thing is I'm not sure how it should look like in game. I assume that allowing party hanging around without protagonist is not an option, so protagonist would need to be bring back after the fight. It could cause some strange situation that I would e.g. need automatically unpetrify character after fight. I know one can argue that teleport to temple and full restoration is even more "strange", but at least you have this "cut" here, screens goes black etc. Also I have feeling that this would make protagonist kind of "meat shield" for the party members, that can die without any consequence. Regarding engine, it's not that bad, combat mechanic is very similar to Diablo II (even critical hit chance is the same if I remember correctly), the problem is indeed in magic. There is too many either/or situations, either you are protected against something, or you need to reload. Maybe at some point it could be addressed somehow, but this is complicated thing to do it right. I mentioned this "not being total conversion" because "diablofication" can be understand in many different ways and I just wanted to state that for me here it's making tweaks when I see potential for them rather then just rewrite whole mechanics. BTW IMO encouraging "no reload" is very RP thing. In fact, I couldn't think of anything that breaks RP more then reloading game. Not stupid at all. I mentioned it "more details" section of readme, but it is for sure important enough to be right away in component description, I will move it. Answer is: protagonist equipment is not dropped, you are resurrected with full equipment. However, dead companions equipment is dropped normally and can be lost as you described. There is definitely room for improvement here. My thinking was: if you play no reload, it is still better to lose some equipment then end whole run. That's why I decided to release like that. I think about "Companions don't drop equipment" component that would be independent from "Character respawn", but in the same time complementary regarding this situation.

That's sounds super promising. I was wondering about something like this, but I haven't a clue how to handle it technically. In my situation it can be super useful to me because I can protect companions as I currently protect protagonist, but instead of triggering respawn I would backup their equipment, remove their equipment and kill them. Then I will need to detect resurrection/removing form party and give back equipment from backup in such situation (+ quest items should be dropped normally I suppose). I will definitely test that. Yes, totally agree. I have in mind something like random generated equipment using some predefined prefix/suffix. So e.g. instead swords +1 all around player could get here and there sword +1 with some small random effect.

I was able to prepare first working version, I released it as part of bigger project called "Diablofication". I created separate thread for it here. If someone is interested in what exactly I mange to achieve in terms of "protagonist resurrection" topic, here is some sum up. In general, I apply on protagonist min 1 HP effect together with some immunities to instant kill opcodes. Then I add to every item/spell that applies instant kill opcodes additional effect (with the same conditions, saving throws etc) that sets local variable on target creature. Then I am able to detect in scripts that protagonist is affected by instant kill effect and I can trigger respawn in temple. To detect respawn place I set on every master area proper global variable in OnCreation() block, I check it later in respawn script and act accordingly. Applying gold and XP penalty is rather straightforward, jus bunch of script blocks that check thresholds and run proper actions (all hidden in cutscenes to not pollute global script, thanks again @The_Baffled_King!).

Diablofication Version: v0.7 (Readme)(Download) Game: BG1 EE v2.6 without SoD Platform: Windows Language: English, Polish Overview: Diablofication is Infinity Engine modification that aims to implement some of the mechanics known from Diablo games into Baldur's Gate Enhanced Edition. Diablofication doesn't try to be total conversion mod. Instead, it tries to understand why certain mechanic is fun in Diablo and introduce some changes to obtain similar result, without turning game upside down. Consequently, Diablofication is collection of components that focus on following aspects of the game: Improvements for “no reload” gameplay, including ones that make this style of playing available for less experienced players. Randomization and diversification of game content. Various hack'n'slash flavored changes, especially focused on increasing game dynamics. Components: Town Portal (Beta) Town Portal is new level one arcane spell that teleports entire party to the nearest temple (or other safe place, if temple is unreachable). Caster receives special ability, that can be used to teleport party back to place where Town Portal spell was casted. Town Portal spell scrolls are added to store in every temple. Those scrolls can be used to cast Town Portal spell be every character that meet standard requirements for using scrolls (regardless of ability to use arcane magic). Identification For All This component changes Identify spell scrolls so they can be used be every character that meet standard requirements for using scrolls (regardless of ability to use arcane magic). Also, Identify scrolls are added to store in every temple. Party Revive After Combat (Beta) Makes all forms of death of all party members (including protagonist) temporary until the end of combat. Game over occurs only when all characters have been eliminated. Character Respawn (Beta) Instead of game over, entire party will be resurrected in the nearest temple (or other safe place, if temple is unreachable). This will however has consequence in certain amount of gold and experience points loss. After respawn, protagonist receives special ability, that can be used to teleport party back to the place where respawn was triggered. Remove Non-Combat Experience Removes experience points rewards from quests, dialogues, thief ability usages and spells learning. Spells Regeneration (Beta) Grants out of combat regeneration of one spell (arcane and divine) per round for all party members (including familiars). More HP on Level One Significantly increases HP amount that protagonist and all companions receives on level one. At the same time, amount of HP gained with every level is decreased, so difference between HP from original rules and those applied by this component is getting smaller and smaller with every level up. More Proficiency Points Increases frequency of getting weapon proficiency points, especially for fighters and other classes that are good with weapons. Camera Lock (Beta) Double click on character portrait locks camera, making it move automatically with character movement, keeping character always in the center of the screen. You can unlock camera using right click on "select all" button. Any feedback welcome.

Thanks for detail response. I can agree this is the bug, I was rather afraid by impact of the change. But if mod compatibility is not a problem I think my position is indeed too conservative. EE introduce many changes that influence gameplay in more drastic way then item deduplication proposed by you. So I can imagine it could be even part of official patch, why not. For nostalgia we always have vanilla games.

I'm a bit surprised that you want include such big change in fix pack, that, if I understand correctly, should be installed pretty much always by everybody (at least other mods can assume it is installed). IMHO this is not "bug" like e.g. some wrong trigger in one of the script blocks or some glitch in animation, its a game design problem. Other examples of such could be: "It was not intended by developers that you can separate group of monsters". Or "It was not intended by developers that you can spam fireball out of enemy visual range and enemy would do nothing about it" etc. If we will consider such things as "bugs" we can merge EEFP with SCS I guess. But that was not intention of EEFP from the beginning (if I get it correctly). Other points that could be also relevant against including it: existing mods could relay that certain items (exact ITM resources) are in certain places. Those would be not compatible with fixpack what is problematic if we see it as "must have" for future installations. this is matter of taste which item appearances are "canon" and which should be replaced. Again, if we want everybody to install fixpack, it should contain not so arguable changes. IMO this is good idea for mod (btw there is already similar one). But I would be careful to include this to fixpack. I really don't see reason that this change should be included in every installation of the game from now on. If this would be separate mod, I personally probably wouldn't install it (scope of the change is too big for given benefit for me).

Answering myself: Setting local variable with opcode 309 on Player1 works. It can be read/updated later in scripts with TriggerOverride/ActionOverride. splstate can be modified, but number of possible values is limited, so better to avoid it if possible (more info) Setting STATE_STONE_DEATH would probably still be cleanest solution, but still don't know if there is a way to set it manually (omitting actual petrification). So far so good with local variable as a marker. This was probably last technical thing that required investigation. I have implemented resolving nearest respawn point with some plot critical restrictions, applying respawn penalty (xp + gold), respawn triggering (normal death + petrification + whole party charmed), some simple respawn process. Still some coding left, but I think it's safe to say that Alpha is on its way.* * Unless I forgot about something that will kick me in the butt at the very end.

IMHO This is exactly kind of fix that should be provided by EEFP. Probably it wan't make to official patch since it not cause any bug in unmodded game but at the same time its clearly original script flaw. Unless this is part of modding best practice to avoid EXTEND_BOTTOM and always EXTEND_TOP + Continue().

I'm getting to the point that I'm starting to understand what you suggested here @jmerry. For normal death prevention I would go for "min 1 HP" option and I would pretend that regeneration problem not exist (for now). In BG1, where my focus is right now, there is not that many instant kill scenarios, but petrification can be good example of such. My plan is to prepare spl file that would apply petrification opcode. I would then replace with WeiDU every case of applying petrification opcode to applying of this "petrification" spl and also replace every petrification opcode immunity with immunity to this exact spl (probably same for cure). I would make protagonist immune to petrification opcode. So at this point everything that I add to my "petrification" spl next to petrification opcode would work on protagonist in cases when normally petrifaction would take place, I guess this would be place for my "marker". As far as marker goes I see couple of eventual candidates: Setting variable in LOCALS as you suggested, but I'm not sure how to read such variable for Player1. Would TriggerOverride(Player1, Global("somevar", "LOCALS", ..)) work when I put it in baldur.bcs? Because AFAIK there is no "local" script for Player1 that is uneffected by "Disable Party AI" button. Setting current hp to 1. For non protagonist creatures it should make no difference, since they would be petrified anyway. Again regeneration can screw up thing here. Also I wouldn't be able to detect in script what was the cause of death, what could be handy to apply some visuals (fake death effect on normal death, stone effect on petrification etc.) Setting some splstate. I guess it could be done with opcode328. Problem is that there is no "petrified" state there and I'm not sure if this table can be extended with custom one. Setting STATE_STONE_DEATH. It is set by petrification opcode, but I don't see option to set it myself omitting this opcode.

Small things from my side. Engine problems that I think don't result with any bug in unmodded game but can be cause of troubles for modders. 1. AddXPObject() action produce awkward feedback message when used with negative values. This is handled correctly for AddExperienceParty(). See screenshot: 2. Reducing XP of character below zero results with maximum XP value for this character. I know that there was many bugs like this in vanilla BG, TBH I don't know if there were fixed in EE. I would expect the same behavior as reducing stat below zero: character death OR it could just stay at zero in such cases (like it is with gold value).

Sure. I will need some time anyway to process all the help that you already gave me. Good luck for you too! Yes, I would also bet on cutscenes. I remember that I tested that but very briefly (it looks that too briefly). StartCutSceneEx would be great for me to avoid big switch blocks that would normally polluted area or global scripts. I saw it somewhere during browsing IESDP, but it didn't bring my attention, now, based on your examples, I can see how cool tool it could be in my case. I would be grateful if you could upload this spl file. I'm just starting with opcodes etc and this could be very helpful for me to see what are possibilities for this. I would definitely try that. I was going to start with StorePartyLocation(), but this is one global state, if other script use it before player choose to go back, my state would be gone.

Hi @The_Baffled_King, thank you for this detailed feedback! That's true, but it's not priority for me. I think that for the first version would be enough if I will teleport to temple for cases where normally would be "game over". But for sure, extending it, so it would happen only when all party members are dead, makes a lot of sense. I backed off form relaying only on "Player1 can die" flag because I experienced problems that make whole solution unreliable. Let's take simplified version of you script in baldur.bcs: I had similar piece of code and I was problem with following test case: start new game enter Candlekeep Inn kill Protagonist Sometimes Protagonist was resurrected, but sometimes, areas was switched to exterior Candlekeep area and game crashes. I think this area switch is related with mechanics, when your party member dies in child area, when rest of party is in master area. Then games switch view to master area. In this case, when it happens before resurrection, game crashes because there is no Protagonist to resurrect on current area (which is now Candlekeep exterior). Moving this script to area bcs file also not helps, crash not occur but either resurrection, so it is not good. Please let me know, if in your approach this problem doesn't happen. Similar problem I had with CopyGroundPiles(). Even if resurrection was successful it usually copied ground piles from exterior area, not actual area where Protagonist was killed. There are some other problems with CopyGroundPiles(): it will copy piles only from one area when in fact different PCs could be killed on different areas, e.g. you fight Mulahey, one of companion is dead in his chamber but Protagonist escaped on previous area, then if Protagonist would be killed there, CopyGroundPiles() won't work on equipment of dead companion. there are ground piles in the game that imitates normal containers, e.g. some of the treasures in Ulcaster dungeons are undestructable ground piles. CopyGroundPiles() targeting them, I've checked that. You could probably replace such cases witch normal containers somehow, but this is for sure additional complication. I decided to skip this CopyGroundPiles() for now. I prevent protagonist death with min hp opcode so equipment is not lost when "dead" (= has 1 hp). I have no handling for retrieving loot of dead companions, but I focus on solo scenarios right now, to make things simper. Interesting. I was trying SetMasterArea() in this context without success, but maybe I will try again using your way. The only thing I'm worried about is this area switching that I mentioned above. It could be that if this switch will occur before AreaCheck(), the your result could be wrong (wrong action block would be triggered). I tested moving Protagonist with MoveGlobal() action and I had problem when moving between areas. Although Protagonist was moved, camera was still on old location and there was nothing to do about it. Maybe MoveGlobalObject() works differently or maybe something else I was missing, e.g. this ActionOverride() wrapper. Would you be a problem for sure to share full codebase of your mod? It would be easier for me to test and compare our solutions, My recent code is currently here. Ah,, that makes sense! Thank you! I totally agree. I bring up this "Chapter X = Resurrection here" concept as kind of minimal implementation, but now I also think that it is not worth an effort to implement this. I will strat with resolving respawn point based on master area right away. This is in general good idea. Has some advantages and disadvantages, but ofc respawn in temple also has some disadvantages too. I started with "temple" approach because imho it fits better to BG1 and it seems to be less work (don't need to create separate area, dialogues, area leave mechanism etc). Resolving correct temple wouldn't be that big a problem from what I see. I'm thinking about adding some kind of "waypoints" in the future, so it could handle need for fast travel after resurrection. But from the other hand, I must say "pocket plane" approach could be easier to extend in future. I definitely would think about that. EDIT I tested your code @The_Baffled_King and it works flawless, I don't know what was my mistake before. This splitting steps between separate custscenes files is great, thank you for showing me this. CopyGroundPiles() still suffers drawback that I mentioned above, but I suppose it's still better solution then my latest version. Do you think having this resurrection in two steps is necessary? I replaced ApplySpellRES("BKPRRP1",Player1) with normal resurrection and it seems also fine.

Regarding penalty for getting killed, here was some discussion about possibility of percentage penalty. It seems it is impossible/very complicated. So the way to go would be penalty based on thresholds. Actually, maybe it will have more sense, since level progression table is not consistent at this point either. So I took fighter level progression (it's simplest) and for each level calculated: (next level xp value - current level xp value) * 10% and I got in result something like this: Level: 1 2 3 4 5 6 7 8 9 10 XP for level: 0 2000 4000 8000 16000 32000 64000 125000 250000 500000 Result: 200 200 400 800 1600 3200 6100 12500 25000 25000 And for every next level also 25000. So I guess I will implement for now thresholds like this: Character XP -> XP penalty >2000 -> 200 >4000 -> 400 >8000 -> 800 >16000 -> 1600 >32000 -> 3200 >64000 -> 6100 >125000 -> 12500 >250000 -> 25000 And those values also make sense to me if look at it as "current party gold -> gold penalty". Any comments welcome.

Ah, yes, that makes a lot of sense. Thanks once more!

So this is used to determine if new effect should overwrite old one? BTW is there a way to check in-game e.g. what are current effect that work on some creature etc? This could be handy. I guess this confirms my suspicion regarding this. So I would go for scripts block for now and eventually come back to this topic when I will have more experience with all of this. Thank you both!

Yes, this is exactly what I want to achieve. I haven't been clear enough. I want to apply one time decrease of XP amount of pary member. E.g. if character has currently 2000 XP will loose 200 XP permanently.

In my modification I want to apply percentage XP penalty for party members. It seems that although AddExperienceParty() action can reduce party experience, it need to be always some fixed amount, I guess the same problem with AddXPObject(). So I started looking into opcodes, and opcode 104 seems to be able to do what I want. First question would be what is the best way to apply it permanently on party members. My idea is to create spell that is permanent not dispellable, something like: opcode: 104 target: Self power: ?? <- what is this? param 1: 90 (10% reduction) param 2: 2 (Percentage Modifier) timing mode: 9 ⟶ Instant/Permanent (after Death) dispel/resistance: 2 ⟶ Cannot be dispelled/Ignores resistance duration: 0 (ignored when timing mode is 9 I suppose) probability: 100 ... rest I believe is straightforward: no saving throw, no dice restrictions etc. Would it work as expected? I mean would it be permanent effect form moment of application till end of the world? Second question is: Is it worth it to do it this way? Maybe it could lead to some problems and this solution should be avoided because of that? For my understanding, effects represent something temporal, it seems that it is not right tool for this job. But as far as I know there is no other one. I could prepare fixed penalties with some thresholds using script actions, but obviously applying it with percentage would be much more easier to me.

It works! I wasn't aware that inside function I can read variables outside function scope. Thanks!