Can we expect any more patches for BGEE, SOD and BG2EE?
Madrict
Member Posts: 141
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?
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?
0
Comments
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.
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.
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.
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.
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.
Anyway, I would pay for a patch/DLC that adds Psionics, Favored Souls and Warlocks to BGEE/BG2EE.
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!
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.
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 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.
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.