Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by K4thos

  1. you're not using EET Worldmap. This is how EET worldmap looks like. from what I see you didn't install patch that adds proper icons to bp-bgt worldmap (included in Big World Fixpack), that's why icons unique to EE games are not displaying correctly. As for the problem - I suspect that's how it works in BG:EE too, so not a bug.
  2. you can play SoD. All BGEE and SoD resources are in your BG2:EE (EET) game. Whatever happened to BG1/SoD folder after EET installation doesn't matter at all (you can even delete it altogether, it’s not used anymore). You can continue your game just fine.
  3. ? No, it's not BG1/SoD patch, even if forced by steam, didn't affect your BG2:EE (EET) game. And it didn't affect your EET saves. ----------- As for creating a new installation I'm working on EET upadate that will support latest SoD patch.
  4. when it comes to bonehill and bp-bgt worldmap I'm afraid I can't help much since I never play with either. Bonehill seems to be supported by Roxanne, but it looks like she is no longer participating in discussions on G3. You may have better chance asking on her site.
  5. all BG1 areas in EET uses BG prefix, so the correct console command is: C:GetGlobal("Gibberdead","BG4600") in your save it's set to 11. The bug is not related to EET. If the same thing happens when you load earlier save and do the quest again then it's some other mod fault (in such case set the value to 12 via console). If you can't reproduce it then it was an engine bug. I've just completed The Gibberling Hordes quest without problems using different save.
  6. open SAVENAME.2DA located in override directory and change this line: 1 103050 7 1 the last column value is a number of quick saves
  7. You can't. This information is in the readme file. The mod uses different worldmap, sets variables along the way which are not present in your save, has renamed resources and moved strings position to not conflict with vanilla BG2:EE. Start new game. Then you will have save that can be reused in different installations (when it comes to vanilla game content, to re-use saves on installations made with different mods you can use this feature, which is unique to EET).
  8. I've noticed on github that the EET related commit modifies shout.baf. It's unrelated to EET. Looks like it's there to fix the problem mentioned in this old topic, which also affected SCS. May be a good idea to review this particular change since there were several patches since 2014 to EE games, maybe it's no longer needed (or could be coded better).
  9. don't worry about the stuff I'm working on, it's not SCS job to adjust to something needed by other mod. It would be nice if mods that do simple true/false checks didn't use stats.ids entries, but let's focus on things that actually need fixing (change introduced in patch 2.5 that breaks old DS implementation): https://forums.beamdog.com/discussion/67571/the-big-is-it-a-bug-or-supposed-to-be-like-this-thread/p6 voting for this. If Kreso's version won't be used as base then I'd like to request internalizing my old patch (it adds EET support, nothing else changed)
  10. doesn't matter. Saves created on BG:EE or SoD would have wrong area names stored in it (BG1 areas in EET uses BG prefix). That's why he ended up in wrong area (area from BG2). edit: when I now think about it Shandalar House is BG area, not BG2 one, which means my assumption that he is loading wrong save is incorrect. Not sure what's the issue here.
  11. one of the mods in your installation is broken (uses ANSI encoding for Spanish tra files instead of converting them to UTF). No matter how many times you're going to re-install the crash will be always there (and would be on BG2:EE without EET too). Even a single string with wrong encoding crashes the game. If it happened when you tried to to open worldmap the most likely candidates would be mods that add new areas to worldmap. There are quite a few in your installation and the only way to find out is uninstalling them one by one. Alternatively you could try using this to export TLK in order to look for broken encoding manually but that would be a lot of work too. Weidu.exe --noautoupdate --no-auto-tp2 --logapp --use-lang "es_ES" --out "strings.tra" --traify-tlk If you find which mod cause the issue please report it to mod author. The problem has nothing to do with EET.
  12. if by BG1 save you mean a save created on BG1 or BG:EE then such save is not supported.
  13. bob_veng, that's exactly what I meant by "variable checks which will be set passively based on character's ability scores and existing skills". Until active skill selection is implemented it has to be simulated with what already exists. What existing stuff should contribute is open for discussion of course. which is appreciated I've finished reading your post and I found a lot of valuable information in it, thank you. Will think about merging some proficiencies together and other proposed stuff once I start implementing this system.
  14. subtledoctor, don't worry, if I will be able to implement this system (as mentioned I'm not even sure if the system will be possible the way I've envisioned it considering it depends on Bubb implementing control over spell casting level and access to disabled cleric scroll), there will be a stand alone version with more options as well. And I don't have a problem with component that removes 2nd ed progression rules all-together from game for example, if there is demand for such feature. The system itself could be also used as a base for other mods. I'm open to collaboration too (keep in mind that work on it will start once I finish IWD-in-EET, not now). But yes, currently I'm designing it with IWD-in-EET in mind first and foremost. There are for example tons of skill checks in IWD2 dialogs, so instead of converting them to ability score checks like I did before, now I'm thinking about keeping them as they are, with this system in mind. For now I'm probably going to convert IWD2 dialogue skill checks into variable checks which will be set passively based on character's ability scores and existing skills. This way it will be easy to implement active skill selection once the system is implemented. IWD2 creatures (even non-humanoids) uses feats, so I've decided to port them over and assign those feat features into cre files. Exactly the same feats would be selectable for player when the system is implemented. etc. If by "this stuff" you mean Lua than maybe. All the other things I'm pretty sure you have more knowledge about. The core of this idea is not really that complicated - most of the leveling system stuff would be handled via external lua code, not really intrusive patching of vanilla spells, items etc. (the only intruisive skill that I can think of would be Item Use, feats are not intrusive at all, multi-classing working like in IWD2 doesn't really change that much, acces to items is handled by using W/M/T class as a base for character following this system, even though we're not using progression of that class) Think about it more like a kit that brings new possibilities (pretty much "create your own kit as you play") not something that will turn the gameplay upside-down. edit: didn't notice your second post, will reply to it once I finish reading.
  15. I've just checked the 2 stats mentioned by lynx (Class String Override Mixed, Class String Override Lower) and they seem like a perfect fit for 2 skills that absolutely require to be stats in order to work as expected: - these stats can be modified by opcode 282 (Modify script state) - they are not used by any mod yet since changing them alters what is displayed in record screen - not a problem for this mod, I can alter what will be displayed - they don't have limited ranges like profiniencies - can be checked in scripts via CheckStat() Overall perfect, without any drawback that I can think of. Thanks!
  16. Thanks subtledoctor. I have few issues with the proposed implementation, though: - it sounds like a hell to implement and test (can't say I understood all of the stuff you've mentioned) - the system is meant to be used alongside classic BG functionality, not replace it (you can still play with NPC using some awesome kit alongside another NPC or player character that follows IWD2 style rules hybrid) - grouping proficiency together would likely conflict with many mods and would force IWD-in-EET to be installed at the very end in order to implement those changes, which is not really something I would like to be the case (like EET, the mod is meant to be open platform that other mods can expand) - updating item descriptions etc. sounds like a nightmare (can be implemented though) All of these headaches just to make items that can increase all skills? Sounds excessive to me considering I've just finished testing this idea and it works as expected. Still not sure why you've mentioned that "Repeating 272 and invisicres are things I try to avoid at all costs. Combining them is my modding nightmare." when it's actually extremly easy to implement (took me like 5 minutes to test it) and seems reliable, unless I'm missing something. edit: those class strings seems like a good idea, considering the characters that follows progression system introduced in this mod don't really need them (we can adjust what is displayed in record screen etc.), but what exactly sets them? Can they be altered via opcodes, detected in scripts, accept values instead of strings?
  17. care to elaborate? edit: simplified the script by moving variable increment into item and spell effects. This way ActionOverride and unique variable are no longer needed.
  18. When I now think about it items that give bonus could still exist for all skills, even if 6 of them is stored only in local variables, not stats. Just make the item use opcode #272 (Apply Repeating EFF) which spawns invisible creature, with script like this: //the item increases "ALCHEMY" local variable via opcode 309 //spell_with_opcode321 has item name as resource to remove further spawning, also decreases "ALCHEMY" local variable IF HasItemEquiped("nameOftheItem",LastSummonerOf(Myself)) THEN RESPONSE #100 DestroySelf() END IF True() THEN RESPONSE #100 ApplySpellRES("spell_with_opcode321",LastSummonerOf(Myself)) DestroySelf() END So I think we're back to just 2 stats (Concentration and Use Magic Device) that are needed with at least 0-20 range. Although I will need to test it first.
  19. good point, completely forgot about it. Here are the currently missing skills stats: - ALCHEMY (Alchemy) - ANIMALS (Animal Empathy) - BLUFF (Bluff) - CONCENTRATION (Concentration) - DIPLOMACY (Diplomacy) - INTIMIDATE (Intimidate) - SPELLCRAFT (Spellcraft) - MAGICDEVICE (Use Magic Device) And here are those that already exists: - DETECTILLUSIONS (Search) - TRAPS (Disable Device) - HIDEINSHADOWS (Hide) - LORE (Knowledge Arcana) - STEALTH (Move Silently) - LOCKPICKING (Open Lock) - PICKPOCKET (Pick Pocket) - TRACKING (Wilderness Lore) - SETTRAPS (this skill actually didn't exist in IWD2) Which means highjacking 8 stats would be better Although if I won't be able to do find good candidates, just 2 is still enough to make the skill system work, even if it won't be as good as it could be. Interesting, I will write a weidu code that analyze all files in game to check which ones are ready for re-mapping since they already use Spellstates. I will post results in this topic. I was thinking about patching all scrolls and wands in game to cast different spell if specific class is using it with checks for MAGICDEVICE value in order to determinate if the casting is successful (splprot.2da checks, maybe additional Apply effects list). I'm not that good when it comes to opcodes, so will need to test what will work first. Will post example item here when (if?) I manage to get it working. Unless Kjeron can confirm that it can't be implemented already. "Can't Use Itemtype" effect is not the way I'd like to implement it. In IWD2 player can use those items. Using them successfully is dependent on dice roll and MAGICDEVICE stat value (increased by modifier) Thanks, will check it out. In this system every single skill, feat, class level etc. is meant to be visible on record screen. Same for level-up stuff (all windows related to it will be rewritten, so that you can select feats, check their descriptions, increase ability points etc. - see IWD2 gui, that's how it's meant to work). GUI is coded in Lua, and with stuff that Bubb is working on it won't be a problem to fetch data into Lua variable that can be displayed: - Infinity_GetLocal(creatureID, local) - Bubb_StoreLocal(S:Variable*,S:Local*) - Bubb_StoreObjectStat(S:Variable*,O:Object*,I:Stat*STATS)) The system will either feel like it had been officially implemented (everything working with GUI, no workarounds that can be noticed in-game like selecting something via dialogue etc.) or I won't bother implementing it.
  20. I don't think so, but modification via opcode is not needed for the mod I'm working on. XPVALUE works with CheckStat and ChangeStat. I need it as stat to make it work with splprot.2da. will skip this one in this case thanks, will check my old topic. if you mean in relation to the design I've proposed the bolded part is not the reason why I need those 2 stat.ids entries. They are meant to be used just for 2 missing skills that can't be implemented without stats: - Use Magic Device - Concentration (in order to implement it properly exe hack to change CONCENTR.2da formula would be needed as well (from Luck into some other stat number). Tracking (Wilderness Lore) is another IWD2 skill that the mod is meant to implement (well, it's meant to bring all of them). Even though this skill doesn't really need stat.ids entry to work as intended I think it would be a bit silly to replace it when it's actually used. May be useful for other mods, if someone decides to take advantage of Wilderness Lore via spells.
  21. In order to implement this system I will need 2 stat.ids entries. Spell states functionality is not an option due to design decisions that Beamdog made (those stats don't accept values and splstate is capped at just 255 entries. I need a range of at least 0-20 per stat, which would be 40 spell states entries - unacceptable in heavily modded game). Hence the question - which stat.ids entry do you think would be a best candidate to highjack? I was thinking about following ones: 1. 31 INTOXICATION - can be made permanent if assigned with timing 9 and its effects don't seem to be present until you reach 50 points (as mentioned I need smaller range). On top of that can be easily checked and edited with CheckStat and ChangeStat in order to reset the value when player drinks booze. The effect can be simulated with ApplySepllRes and I don't think any mod uses this stat yet, so I think this one is pretty safe bet for one of the 2 stats needed in my mod. 2. 43 XPVALUE - other than XP that the character gives when killed I don't think this stat is used for anything else when it comes to Player1-6. On the other hand it would be a bit jarring if player decides to kill party NPC and see for example "3 XP gained" message, so maybe it's not the best candidate. Although I will use it if there won't be a better proposal. 3. 134 EXTRAPROFICIENCY20 - unlike other entries this one doesn't use name introduced by Detectable Spells mod. Is it used for anything in vanilla game? I'm pretty sure some mods may use it but if it's not related to commonly used Detectable Spells than conflicting with such mods is acceptable. 4. Moving one of the Detectable Spell entries into splstate.ids. Which of those DS stats requires check that is simple True/False and don't need value increasement, though? Maybe one of them is obsolete in EE engine? Any ideas?
  22. K4thos


    just an update how IWD2 level and class rules will be implemented (if Bubb succedes with expanding the engine functionality): https://forums.beamdog.com/discussion/comment/1001653#Comment_1001653 Crazy ambitious plan but with the lua access it should be doable (I've worked with lua before) The idea for this system came during Feat spells conversion – since thier bonuses are implemented for creatures, why not add Feats as an option for player as well? This system hopefully will satisfy those who prefer 3rd edition rules introduced in IWD2.
  23. Bolded part is not true anymore. Tested with Range 100 - works fine. And unlike See and LOS, Range actually ignores all obstacles (walls etc.).
  24. The cap is not present in EE patch 2.5. Tested with See() trigger and visual range set to 100 with this opcode.
  • Create New...