Skip to content

Can we expect any more patches for BGEE, SOD and BG2EE?

Hi all,

I am thinking about doing another playthrough of the series with some mods, but I am wondering if I should hold off a bit and wait for any new patches.

Has anyone heard anything about future patches for these games or are they pretty much done?

Comments

  • lefreutlefreut Member Posts: 1,462
    edited November 2019
    ***
    Post edited by lefreut on
    Madrict
  • GallowglassGallowglass Member Posts: 3,356
    Yes, don't wait.

    Eventually Beamdog will presumably bring the BG series (and indeed IWD) up to v3+, where PsT already is. After they've completed the current minor patch to fix some bugs in PsT, bringing all their other products up to the same version (including mobile editions, at long last) is quite likely their next project. I expect it'll take a while, though.

    There'll then almost inevitably be another minor patch to fix further bugs which emerge from the v3 upgrade, but it'll probably not be done for a year or two. After that, however, I suspect that they'll draw the line and cease work on Infinity Engine products.
    QuartzJCDenton
  • The user and all related content has been deleted.
    MirandelQuartz
  • batoorbatoor Member Posts: 676
    edited May 2017
    I think the Void weapons as they are need a slight buff, but I'm not sure if that applies as too much of a change for people or if anyone even cares. I don't have a problem with most of the SoD->bg2 items..but those void weapons have little to no use as they are imo.

    Also making the Commanding and Jovial voice sets from SoD available in BG2..for bhaalspawn pc consistency.

    For the latter I'm guessing EET would solve that, but not everyone will use that mod.
    Post edited by batoor on
    Gallowglass
  • JuliusBorisovJuliusBorisov Member, Administrator, Moderator, Developer Posts: 22,714
    The team's efforts are now on finishing the 3.1.3 patch of PST:EE. Thus, it's difficult to give estimates about projects that will follow. We will be able to say more about future plans on our blog after that patch is out.
  • megamike15megamike15 Member Posts: 2,666
    i think we getting one last patch and then beam dog is moving on.
  • AndreaColomboAndreaColombo Member Posts: 5,524
    I sure hope not, given the amount of stuff that is outstanding on Redmine (and that's just the public portion available to us.)
    Aerakar
  • The user and all related content has been deleted.
    Quartz
  • tbone1tbone1 Member Posts: 1,985

    Technical question: Weidu mods operate to a large degree by patching the values of specific bits in game resource files. I think I saw someone suggest that the update to 64-bit may change file structures and cause this to fail... should modding folks be concerned about this?

    In theory, no, but anyone who has had to do conversions knows to expect it.
    Gallowglass
  • GallowglassGallowglass Member Posts: 3,356
    Yes, as @tbone1 says. It's a fair bet that 64-bit conversion will instantly break most mods, regardless of all good intentions to the contrary, simply because such conversions are inevitably a major change to underlying code layout in memory. In particular, mod installations which depend upon editing bit-field flags will likely fail, because the offsets (and the corresponding XOR masks) will now need to be in 64-bit format, and it'll often turn out that they haven't been set up that way.

    However, with luck, a 64-bit update to the shared installer (i.e. Weidu) might be able to solve the problem simultaneously for many mods, and avoid the need for each individual mod to be separately updated ... maybe.
  • FlashburnFlashburn Member Posts: 1,847
    Are the memory leaks ever going to get fixed? BG1EE/2EE both crash once their memory usage hits around 1,200,000K when viewed in Task Manager.
    Gallowglass
  • [Deleted User][Deleted User] Posts: 0
    edited June 2017
    The user and all related content has been deleted.
    AndreaColomboGrond0ThacoBellLoldrup
  • GallowglassGallowglass Member Posts: 3,356
    What 64-bit conversion will compulsorily change is how code is loaded and addressed in RAM.

    It similarly changes the "natural" way of storing data (both executables and resources) in files, but not quite so compulsorily; code meaning "write this integer 0 to disk" would now write 0x0000000000000000 in the disk file by default, instead of 0x00000000 previously. I suppose you could force it to read and write 32-bit formats for resource files (er ... hmmm, if your o/s doesn't forbid it ... which it might), but you'd have to re-write file I/O commands in the source code. How easy that might be to do would depend on how the existing code is written (about which I have no idea - I don't even know what language the source code is written in), and forcing a format conversion at every read and write would be inherently inefficient code which would run slower than I/O using native lengths.

    If you were starting with a blank slate, no way would you choose to force inefficient format conversions at I/O. However, given an installed base of legacy-format data, I suppose you might do it ... although it'd likely make a pig's breakfast (and therefore a bug-magnet) of your I/O code, so you'd do it only reluctantly. The more elegant coding solution would be one-off conversion of disk files to using the new natural lengths of data, i.e. change everything.

    Without forcing format conversions at I/O, you'd end up with everything stored on disk in the same sequence as before, so the same gross structure, and it'd generally make no visible difference to processes which use data a whole integer (or more) at a time. Where the difference would become visible, however, is in processes which access data at less-than-whole-integer lengths ... such as addressing bit-field flags. Integers used as bit-fields (which is how bit-fields are usually implemented) would now (by default) be 64 bits long instead of 32 bits long, so you'd therefore need to address them with 64-bit masks to pick out the correct bit to flip, and where multiple bit-field integers were concatenated into an array, the offset from each field to the next would be 4 bytes longer than it used to be, and so on.
  • tbone1tbone1 Member Posts: 1,985
    Things written from and to files will likely be okay. You still need to test them, but that isn't likely to be much of a problem, because1) that process is going to use a more-or-less standard set of tools that use system and library calls which will do a lot of the bit-twiddling for you, and 2) Beamdog is going to test the reading and writing of files as part of their own development. I'm not saying there will be no issues, but without knowing the code, I would guess the issues there to be minimal.

    Once you start bit-twiddling in memory, then things can more likely change. It's still not as bad as going between different companies' versions of Unix in the old days, or (God forbid) between Windows and another OS, but still, it is a change.
  • JuliusBorisovJuliusBorisov Member, Administrator, Moderator, Developer Posts: 22,714

    Technical question: Weidu mods operate to a large degree by patching the values of specific bits in game resource files. I think I saw someone suggest that the update to 64-bit may change file structures and cause this to fail... should modding folks be concerned about this?

    The 64 bit change does not modify the file formats on disk. If a Weidu mod patched specific bits in the .exe (as some did ages ago), those wouldn't work with the 64 bit binary.
    AndreaColomboQuartz[Deleted User]elminster
  • RaduzielRaduziel Member Posts: 4,714

    The team's efforts are now on finishing the 3.1.3 patch of PST:EE. Thus, it's difficult to give estimates about projects that will follow. We will be able to say more about future plans on our blog after that patch is out.

    Poor IWD...

    Anyway, I would pay for a patch/DLC that adds Psionics, Favored Souls and Warlocks to BGEE/BG2EE.
    AerakarMadrict
  • MadrictMadrict Member Posts: 141
    Raduziel said:

    The team's efforts are now on finishing the 3.1.3 patch of PST:EE. Thus, it's difficult to give estimates about projects that will follow. We will be able to say more about future plans on our blog after that patch is out.

    Poor IWD...

    Anyway, I would pay for a patch/DLC that adds Psionics, Favored Souls and Warlocks to BGEE/BG2EE.
    I would pay for that too, lol.
    Aerakar
  • klatuklatu Member Posts: 108
    edited August 2017

    Yes, as @tbone1 says. It's a fair bet that 64-bit conversion will instantly break most mods, regardless of all good intentions to the contrary, simply because such conversions are inevitably a major change to underlying code layout in memory. In particular, mod installations which depend upon editing bit-field flags will likely fail, because the offsets (and the corresponding XOR masks) will now need to be in 64-bit format, and it'll often turn out that they haven't been set up that way.

    However, with luck, a 64-bit update to the shared installer (i.e. Weidu) might be able to solve the problem simultaneously for many mods, and avoid the need for each individual mod to be separately updated ... maybe.

    I'm not a WeiDU engineer, but I can pretty much guarantee you that an engine switch to 64-bit will have absolutely NO EFFECT on WeiDU compatibility.
    WeiDU deals exclusively with files (not with memory) loaded by the game. Even if the game is ported to a 64-bit memory address-space, it won't change how it reads 32-bit, 16-bit or 8-bit values from a file.
    So rest assured. The actual file formats would be unaffacted by such a change. And mods WILL continue to work.

    Edit:
    Oops! Turns out @JuliusBorisov already answered this. Still, it doesn't hurt to emphasize this: Mods will continue to work!
    Grond0AndreaColombo
  • JumboWheat01JumboWheat01 Member Posts: 1,028
    Raduziel said:

    Anyway, I would pay for a patch/DLC that adds Psionics, Favored Souls and Warlocks to BGEE/BG2EE.

    I'd totally be up for adding Favored Souls to the game, though they'd probably end up like Shamans and not get their own stronghold.

    I don't know enough about Psionics to say one-way or another, but I do wonder how Warlocks would work in 2e rules and the IE games, considering their main claim to fame is Eldritch Blast spamming. Imagine having to keep hitting Eldrtich Blast every single round.
  • RaduzielRaduziel Member Posts: 4,714
    @JumboWheat01

    Enabling strongholds for Favored Souls and Shamans are quite easy. The problem here really would be a stronghold for Psionic or Warlock.

    For the Psionic I would give a closure to The Hidden matter in BG2.

    For the Warlock, I'm out of ideas.

    And I see no problem hitting EB every single round, as I don't see in hitting anything else every single round.
  • The user and all related content has been deleted.
    ThacoBell
  • RaduzielRaduziel Member Posts: 4,714
    @subtledoctor I'm a big fan of your Psionic mod, but having access to hard coded stuff allows the class to be implemented as in PnP I think.

    The philosophical problem does not exist: the Complete Psionics Handbook is pretty clear about that psionics are and what they do.

    And to keep track of PSP a new space could be created on the character sheet, where Turn Undead appears to clerics for example, with the total and current PSP: Like 200 (150). And every time a psionic power is used a string could tell the player his current PSP so it won't be obligated to be always checking the sheet.

    Of course, AFAIK this can only be implemented by Beamdog due to the "hard coded" nightmare.

    For Warlocks, yeah, I totally agree that EB could be used as a ranged weapon with 1 APR and the possibility of missing sometimes. That would solve the multiple-clicks problem and balance the class to a 2Ed scenario.
  • 11302101130210 Member Posts: 381
    I'm really hoping they'll patch the "Narlen's Heist" quests. My brother is playing the game alongside me now, and he ended up getting to the quest's location, and Narlen was nowhere to be found!
  • RaduzielRaduziel Member Posts: 4,714
    1130210 said:

    I'm really hoping they'll patch the "Narlen's Heist" quests. My brother is playing the game alongside me now, and he ended up getting to the quest's location, and Narlen was nowhere to be found!

    Finding him is tricky sometimes. I myself had this "bug" multiple times only to found that I was looking in the wrong place or at the wrong time of the day.
    ShikaoStummvonBordwehrThacoBell
  • AerakarAerakar Member Posts: 1,015
    Narlen only appears in front of the Sturgeon after dark, e.g. 10pm-6am if I recall correctly.

    I do so much hate the BG1 quests that have NPC appear only at certain times! The close-by Brielbara also appears only at certain hours during daylight, and then there is the Ulcaster ghost strange hours.
    ShikaoThacoBellDoubledimas
  • RaduzielRaduziel Member Posts: 4,714
    Aerakar said:

    Narlen only appears in front of the Sturgeon after dark, e.g. 10pm-6am if I recall correctly.

    I do so much hate the BG1 quests that have NPC appear only at certain times! The close-by Brielbara also appears only at certain hours during daylight, and then there is the Ulcaster ghost strange hours.

    Enable Console Commands and Ctrl + T
    Aerakar
Sign In or Register to comment.