anek

The corresponding folder was available, but the proper separation of files was not enforced in any way and thus not done consistently by different programs (and not at all by many older programs). There is a good reason behind this, see my first post in this thread. Not the separate LocalLow folder, that's just lazy design not to mention bad naming. But the Local vs. Roaming distinction, that is indeed sensible. Yes, and on Linux it's not a pain in the arse at all. The reason is that the principle itself, of separating the files like this, is neither obscure nor complicated to learn/understand. It's logical and practical. It's just that Windows Explorer (and the "open/save file" dialog on Windows) makes it unnecessarily difficult to access those locations. The starting location for file browsing on Windows is, depending on how you browse, either Desktop, or My Documents, or that "Documents library" thing that adds another virtual layer on top of the folder structure. From none of those starting points is there a really quick way to get to C:\Users\<USER NAME>\AppData\, plus as someone has mentioned some version of Windows have these files hidden by default and require you to change folder options to see them (although, I think, that is also true for the contents of C:\Programs\). On Linux, the starting point for file browsing is /home/<USER NAME>/, and the folders for user-specific application data are right there inside that folder (e.g. /home/<USER NAME>/.config/, and /home/<USER NAME>/.local/). Their names start with a dot, thus most Linux file managers will hide them by default, but make it easy (like 2 clicks) to switch between showing and hiding them. Getting to things like save-games and INI files is quite convenient this way. The usability limitations of Windows Explorer should not be mistaken for disadvantages of the general principle of separating application data in this way. And Microsoft happens to have chosen C:\Users\<USER NAME>\AppData\ as the location to be used for separating out user-specific application data, so app developers should simply use this location. I've seen some Windows games do the separation, but put the user-specific files like save-games in My Documents\<GAME NAME>\ instead, so users would find them more easily. I think this is a bad idea. If it's too difficult to get to the location that Microsoft has chosen for those files, that should be fixed in Windows Explorer itself. In the meantime, Windows users can manually create a pair of shortcuts in the Start Menu (or Desktop or Documents folder or wherever is convenient), e.g. in the case of Vista/7: My Application Data ---> C:\Users\<USER NAME>\AppData\Roaming My Application Data (machine-specific) ---> C:\Users\<USER NAME>\AppData\Local

It's only confusing because users coming from older Windows versions are not used to it, and some programs have already switched to this scheme while others haven't yet. In Windows 8 and beyond, it seems this will be the standard (and possibly only supported) way how it's done though, so future Windows users will learn to look for user-specific application data in "C:/Users/<USER NAME>/AppData/" from the start, so it will not be confusing to them. To them, "C:/Programs" will seem mysterious and something to be never touched.

"C:/Users/<USER NAME>/AppData/" is not fundamentally more hidden then "C:/Programs/". Both are places that newbies will not dare to browse by themselves (they tend to stick with "Desktop" and "My Documents/Pictures"), and hence users have to be told about the folder's location in the manual if they are looking for save games and INI files. And once a user knows where to find them, there's not really a difference. If you need to access the save-game folder often (which shouldn't be the case), you can create a Desktop shortcut or something. The fact is that these are the paths which Microsoft has chosen for these purposes, if you don't like them complain there or switch to another operating system that has chosen more accessible paths. I for one don't think they're that bad. Uhm, no, the opposite. Old fashioned Windows games write lots of stuff into their application directory, so if you've had it installed for a long time and played and tweaked it often / installed some mods / etc., it was not uncommon to reach a point where the installation was screwed up beyond recognition and in order to fix it one would have to throw it all out and re-install the game from scratch. Keeping the program directory immutable, means you never have to re-install it. Worst case scenario, you'd have to delete the user-specific INI and mod directory in "C:/Users/<USER NAME>/AppData/" to return to the post-installation state. But this is exactly what the proper Linux-like separation of files would avoid! If save games and settings and mods and everything is written directly into the installation directory, you'll have to backup this whole directory (many GB) in addition to the original installer (also some GB). If the files are separated like I described, you only need to backup either the original installer or the installation in "C:/Programs/" (which never changes after installation), plus the user-specific files in "C:/Users/<USER NAME>/AppData/" (likely only a few MB). But you're assuming that just unpacking is all the PE installer will do, so the resulting installation would be identical for every windows version. I'm not so sure this is a valid assumption. Windows XP and Windows 8 are very different systems, the Obsidian developers may not want to limit themselves to the lowest common denominator. The installer could unpack different executables for each of them, or at least set different registry options depending on the system. Moving registry options into INI files would not change this. It could be an option. I still think that your particular use-case (dual-boot installation sharing) is not mainstream enough to warrant any special attention, but it could be useful for portable USB stick installations. However, it should only be implemented if it doesn't require any considerable development effort, and it should definitely not be the default for normal installations.

Although the quests in the Drow City in the Underdark were actually timed, I think. I agree with your overall point though.

BG2 (at least with ToB installed) also has shift-click for setting simple walking waypoints, but it's not that great (each time a waypoint is reached the character pauses for a short time, slowing him down overall).

The closest you can get to that in BG2, is to enable "auto-pause when finished casting a spell", and then wait for for the game to auto-pause before giving the next command. You'll still have to give the commands one-by-one, but at least you won't waste any combat rounds in between and won't accidentally give a new command before the spell has properly finished casting. While I hope the auto-pause solution will be available in PE, I agree that having a queue feature in addition to that could be useful too.

What's the point? It would only work if you dual-boot multiple identical or very similar operating systems for which the installed files would be exactly the same (there's a reason applications have installers - they can install different things and install them in different ways for different systems, like say Windows XP vs. Windows 8 ). And even in the particular use-case of having a dual-boot setup with multiple quasi-identical systems, all your idea would save is a few minutes of time of performing a one-time installation. I don't think that's worth making any compromises with potentially negative side-effects for... Storing save-games (or INI files or any other user-specific data, for that matter) in the application directory itself is a bad idea. It makes the application directory more messy, makes it more difficult to re-install the application, makes it more difficult to migrate the user-specific data to another PC or to make a backup of it, makes it impossible to use the same application installation from different user accounts without affecting each other, makes it impossible to maintain a proper filesystem security scheme, ... It's the old-fashioned Windows way of doing things - Mac and Linux have moved away from this long ago, and Windows is now also slowly following (since Windows 7). I think PE should follow the official Linux way of organizing application-related files, in order to keep things clean, neatly separated, and secure: The application is installed into a directory on the system drive (like "C:\Programs\<application>") to which only the Administrator has write access, but every user has read access. The installed files are never modified in any way when the application is used - the only scenario in which they change is if the Administrator installs a patch or new version or uninstalls it altogether. When the application is run from a user account from which it hasn't been run before, it automatically creates a set configuration files and a save-game folder, mod folder, etc., inside a directory to which this user account has exclusive read and write access (like "C:\Users\<username>\Application Data"). From then on it uses those files whenever it is run from this user account. In fact, under Linux those user-specific application files are further separated into two directories: One for machine-specific settings, like INI files that specify the screen resolution, sound volume, ... - i.e. things which you will probably set to a different value for each PC/laptop/tablet on which you install the application. One for all machine-independent data, like save-games, installed mods, INI files that specify game difficulty options, ... - i.e. things which you may want to sync between your PC and your laptop/tablet, so that you can continue playing on the train where you left off at home. The advantages should be apparent.

If they're anything like the BG2 romances, they are optional. Simply don't be super-friendly and patient and understanding 100% of the time when talking to your NPCs, and no romances will even start. In the case of Monte Carlo, if he talks to game NPCs anything like he talks to people on this board, he shouldn't have anything to worry about...

The GOG.com version has worked fine for me in that regard. I see no reason to get the EE version except for the tablet support, and even then I'll wait for some player reviews first.

True, a god whose name/history/avatar/properties, or even his very existence, is a closely guarded secret among his priests, could make for an interesting story.

Well, there are also many interesting story and lore possibilities that become available thanks to this very mechanic. It opens up a huge (and credible) source of conflict between gods and between groups of believers, and conflict makes for good stories.

I heard that some software companies like to let their developers create a completely functioning full-featured prototype for a new software product, and then (no matter how well it works) discard it and let the developers design and develop it again completely from scratch, without being allowed to reuse any code from the prototype, but learning from the design mistakes and problems that they encountered with it. This is supposed to result in more robust software design and save the company money in the long run (less cost for fixing bugs and providing customer support). But maybe that's just an Internet myth...

Meh. Forgotten Realms already borrowed far too many ideas (down to actual names like 'Bhaal') from Biblical mythology. I always found that pretty lame and unimaginative. A fantasy universe's mythology should be able to stand on its own - keep real-world religion out if it.

I liked how in BG2 one of the goddesses was "missing", i.e. there has been no sign of life from her in a long time, but the "true believers" still worship her and are certain that she is still alive somewhere and will return when the time is right. And a friendly neighbor goddess takes over her duties (like giving divine powers to her priests) in the meantime...

Awesome! I encountered too many a' wizard in the Infinity Engine games who wasted his entire Time Stop placing multiple redundant high-level spells on some wimpy summoned creature of mine that wouldn't have lived much longer anyways, while he could have easily killed off or disabled several party members instead. ...or stubbornly emptying her whole spell repertoire on the one party member that happens to be highly magic-resistant. ...or failing to put up a common on-demand protection spell that could have saved his life. ...or killing her own allies with area-of-effect spells. But as other have mentioned, the biggest weakness of the Infinity Engine AI's was not their simplistic spell tactics, but rather their helplessness against cheese such as: setting traps around a blue-circled monster right in front of its eyes, without it turning hostile, or - after you attack it - avoiding the traps luring away and fighting a single enemy, while his buddies - although only a few feet away and thus clearly in hearing range - stay where they are, as long as no party member has entered their line of sight yet throwing a multi-round area-of-effect spell or a bunch of summoned creatures into a room and closing the doors hit-and-run, so the monster persistently follows the character that attacked it first, instead of giving up the chase and turning to more immediate threads when it is clear it isn't fast enough

How about spells that give Wizards really good melee fighting capabilities for a short time, like "Tenser's Transformation" in BG2?

If the cutscene scripts can actually specify the individual animations (e.g. show animation of spell X), then using this system for battle replays should be possible by simply generating such a script on-the fly during each battle. However, if cutscene scripts can only specify actual character actions (e.g. cast spell X on Y) to be executed by the engine, then it would indeed not be useful for replays as each time the action is executed the associated dice rolls would end up differently. Come to think of it, I think this is indeed how cutscenes worked in the Infinity Engine games. So yeah, you might be right that replays would need a completely separate recording system even if cutscene sequences are already supported...

Just like I feel somewhat amused whenever I see a castle / tower / multi-level-dungeon / etc. in a video game that doesn't show the slightest hint of structurally sound engineering, and would surely collapse under its own weight in the real world. Or like an evolutionary biologist would likely shiver at the sight of many of the monsters and fantasy-animals that appear in video games, and wonder how they ever came out on top of the survival-of-the-fittest selection process, with their ridiculously impractical body shapes and all... I'm sure there are many other examples. And while some amount of world realism does add to the immersion and shows the designers really care about their world, I don't think it's necessary to be overly pedantic in this regard. "It's fantasy" is a valid excuse.

I think cold and human-hostile environments can really add to the atmosphere of danger and risk and purposefulness of an adventure quest and make it more exciting and "vivid". And such environments can still be very much beautiful at the same time, maybe even more so than grasslands and lush forests. Take a look at the Icewind Dale games, I think the way the environment was done there is pretty cool (pun intended).

How do you know it won't be? As I already explained in another thread, the Unity engine is not the actual cRPG game engine for PE like the Infinity Engine was for BG. Unity is just a low-level framework and toolset on which Obsidian is building its own custom cRPG engine, which in turn will run the game content that will make up PE (and maybe additional games in the future). So how do you know that replaying of scripted battle sequenced will not already be supported by this engine anyways? It might very well be, for cutscene-like sequences etc.

There were various battles in IWD2 after which I wished a replay feature would be available. Interestingly, I don't think I ever missed it during the BG games though.

Adventures are not vacations.

OTOH it make the choices during level-up more meaningful.

Erm, no it wasn't. You could set the BG speed so high (if your computer could hack it) that the characters looked like they were on meth. It was hilarious. Overall game speed is a separate issue from walking speed.

I preferred the BG2 walking speed, which was quite a bit faster than in BG.