Hormalakh

Yeah it does, actually. Who the hell makes an IE successor without left click move, what is that Same with making a Ghost Recon game without right mouse run, that's blasphemy. The same ones who add AoO, 3d models, dynamic maps, a different rule-set, etc etc etc etc

After playing the game a bit and then watching players like Shevek who could care less that their party members get KO'd in a battle, it seems to me that the disincentives for having your party members stay alive is minimal. This is especially true if you were to have a party member with high hitpoints who would likely survive long enough to get back to camp for healing and resupply. I would suggest having some sort of additional damage added to health if a party member gets knocked out. For example, as health is 4-6x the normal endurance currently, with each knockout, there would be a 5-10% additional damage done to total hitpoints/health. Something that makes KOs scary but not game-breaking. This way, a player who barely scrapes out of a battle is still in a better position than one who gets KO'd. It incentivizes repositioning during battle. Oh, also: get rid of AoO. It's poorly implemented and a huge headache. Think of other ways around your problems with kiting: AoO doesn't do it.

I got my physical copy when I backed.

The "way IE does it" doesn't mean we have to follow that. I don't see "let's follow the terrible UI of the IE-games" in this: In fact, there are plenty of other changes made to this game as compared to IE-likes. Creating a better and more modern UI should be one of those additions. Just because IE had terrible UI implementation, doesn't mean we need to recreate those mistakes. I couldn't agree more with all of rumsteaks comments. good stuff.

I wrote this a while back but I wanted to post this here to see if people like the ideas and some renewed discussion about the skills system. Ok here goes. I spent all day a while back designing a few changes to a bunch of the skills to both balance them and make them more interesting for each player to want to use. Before I get started, I sat and thought about what each skill needs to be interesting to play and advance. 1- to have a benefit to a player who dabbles. 2- to have a benefit to a player who masters. 3- does NOT need to have a combat oriented benefit to be considered useful. 4- to have proper feedback given to players when choosing them (like attributes currently do). This is the proper solution to Josh's "mindless advancement" issue. Players are making mindless advancement because we don't have actual data to make decisions. Just nebulous, hand-wavy descriptions that give no tangible facts for players to gauge effectively. I identified 5 mechanics (outside of combat) that the skills should affect. 1.Stealth, 2.camping supplies resource management, 3.locks and traps, 4.consummables, and 5.Dialogue. These 5 mechanics (plus one additional mechanic that I created and I will talk about later) are what the skills should effect. --------------------------------------- Athletics: Currently is probably the best implemented, because as has been said, you need every party member to have it otherwise they fatigue too quickly. This effects their camping supply resource management and combat effectiveness. As it stands, the athletics skill is one of the better designed skills. As for feedback during skill progression for athletics, it should give an approximate "life-cycle" for a character before they get fatigued. So during advancement, it should say something like "This party member can adventure for approximately 21 hours before becoming fatigued." I know that the number depends on how many battles you get into, but just having some information is better than no information. Increasing the skill level would change the number of hours and gives players direct feedback. ------------------------------- Lore: Currently, the worst implemented. Bestiary information is really easily meta-gamed and doesn't provide much benefit to players who are "serial power-gamers" (and these are peoople too). I considered different mechanics for lore and I think the one that fits the skill best is having an affect on dialogue choices. As dialogues currently go, there are in effect, hard limits on whether your party can by-pass the skill check needed for a dialogue. I considered the lockpick mechanic used for locks and thought that lore would fit this "lockpick" mechanic well. How it would work is that lore would provide a bonus to dialogue checks based on the cumulative level of lore of the party. A bonus (+1 up to and including +6) can be added to any dialogue check (only dialogue, not scripted interactions). Each level of bonus is determined by the party's lore level in the following way: CHAR1 + CHAR2/2 + CHAR3/3 + CHAR4/4 + CHAR5/5 + CHAR6/6 where CHARX is the lore level of a party character, ordered from highest to lowest lore level. The dialogue bonus is then determined using the same advancement that skills progress (triangular number advancement): thus for a +1 to dialogue you need a lore sum of 1, +2 needs 3, +3 needs 6, +4 needs 10, +5 needs 15, +6 needs 21. Thus, players who dabble can quickly reach up to +2 in dialogue bonuses, but players need to consider mastering 1 or 2 party members in lore to get up to +3 or +4 in bonuses and need multiple party members (2 or 3) to master lore to get +5 or +6. Lore is knowledge and knowledge can be useful in conversations: you can use it to convince others about what you need or want. At the same time , two heads are better than one. The more people with lore knowledge, the more likely you are to have the information needed to convince someone. However, as you have more people, the information is more likely to be redundant, and so each party member that is added to the equation gives increasingly less benefit to the dialogue bonus. This is the best way to have players seriously consider lore as a skill because it gives real, tangible benefit to the dialogue mechanic. It has been stated that apparently Josh shot down a similar idea in the past because he said that it makes it harder for designers to design skill checks and harder for players to recognize how much they need. I would argue that the whole point of implementing skillpoints in lore is to make all dialgoue choices easier by giving a similar mechanic to how lockpick works. The additional point in whichever check is helpful, but not superhelpful as to make investing in other skills worthless. Bestiary information can continue to be a part of the skill. However bestiary XP should be removed. Feedback during advancement would give you your total lore score (using that equation provided above) as well as the dialogue bonus score (+X). ----------------------------------- Stealth and Survival: No changes. ------------------------------------- Mechanics: As it currently stands, the mechanics skills is super redundant. There is no reason to have more than one trapsetter or master lockpick. I started to think about what a mechanics skill is and realized that it's the ability to fiddle with items that have multiple parts and are "contraptions." It's the steamwork skill. So this means that the mechanics skill should affect complex weapons as well. So I sat down and looked at the weapons. Surprisingly, all the complex weapons are ranged ones: arbalests, pistols, crossbows, arquebuses, and blunderbusses. And they are powerful ranged weapons. There are two other ranged weapons (bows and war bows) that I will ignore for now. I thought that these weapons should have a mechanic that would make them more "balanced" without using the same tired old things that Josh uses for all his other weapons. It can also help balance the property of ranged weapons which cause "kiting" and where AoO has tried (and failed ) to fix. That mechanic is "jamming." The way jamming works is that these ranged weapons have a chance of jamming upon use depending on how impressive the weapon is (arquebuses 15%, pistols 5%, etc etc). If the weapon jams, the player cannot use that weapon for a duration of time until he unjams it (1 - 2 turns). The mechanic skill would then decrease the duration it takes for unjamming the weapon by a percentage (since Josh loves weird numbers). Thus the mechanic skill has a reason for every player to get it: it allows you to increase your DPS when using "mechanical weapons" as mentioned above. It also helps adjust heavy ranged weapons with a different mechanic so as not to have to balance around decreasing damage and other adjustments that have been tried. Feedback for this skill would show the duration decrease with every level of the mechanic skill. ------------------ Ultimately, I think that Josh's argument that players are making mindless decisions about skill progression isn't really their fault when they don't have a strong understanding about what each skill provides them. This, along with the poorly balanced skills (lore and mechanics being the two that need the most work) makes skill progression fairly mundane. I want to reiterate my dislike of mixing talents and skills together as it has been done. It really limits what players can do and want to do and goes against the idea of a "customizable" character that is the mainstay of RPGs, especially IE ones.

This was the one biggest feature I was looking forward to. Unfortunately, I haven't had a chance to play the beta much since my angry rant a while back (I've been burned too many times). When I did play, I couldn't figure it out. I'll give more feedback when I get a chance to play with it. On the weekend or something.

My solution is to scrap the whole engagement mechanic, since it's clearly going to be massively buggy. But i'm sure no one wants to talk about that. The NWN series had the same thing, with exactly the same problems. Sometimes when you try to run around your opponent, you would get hit instantly by 2-4 attacks of opportunity, because the position checking was buggy, and your pathing AI would screw it up. I was against the idea the first time Josh mentioned, however no one really listened, so i'm not even going to bother with that argument anymore. It's fine if you post your suggestions, i'm just telling you what i think would cause problems, based on my personal experience with the beta. Sorry for the extremely late reply. As time continues to pass, this is becoming more and more likely to be the right answer - getting rid of the mechanic altogether. I was skeptical at first when AoO was mentioned (not having played other games like NWN which had a mechanic similar to this) and said that if it was to be implemented it had to be done right with edge cases considered and solutions implemented. It just seems that they don't even have the mechanic working correctly in the first place with all the bugs, let alone making sure edge cases are considered. If the mechanic is too difficult to get right, I'd rather they get rid of it and come up with more intuitive solutions to their problems (kiting and ranged weapons). Other solutions have been mentioned and should get tried as well. Non-creative approaches to difficult problems will continue to give the same old problems as before.

What I mean is that it's working as it's intended here in Pillars of Eternity. It's not exactly like the IE version, you're right. In this version it seems that mouse-over overrides selection status. That is so to say that if you mouse-over an enemy, that takes precedence for showing who's attacking who over your having selected your ally. It's more of a preference than it being a bug. IE took selection as its preference for showing who's attacking who. Of course, this is up for debate and you can get into confusing cases (multiple people selected, how do you show who's attacking who? are all the targeting reticles active now?)

Good video. Thanks for uploading. Your video allows me to see how wildly varied your gaming experience and mine are: none of the glossary things that you mentioned worked correctly for me. 1- The first thing I noticed was that the green selection circle is completely camoflaged by the grass: can we go a little more neon in the green tint for the enemies? 2- The mouse-over reticle disappearing is not a bug. If you mouse-over the enemy, it will show you who the enemy is targeting. Since the enemy is idle and not targeting anyone (including himself) then it becomes solid. If you mouse-over anyone or select them, it shows who they've targeted. It's not a bug and is working correctly. More comments to come shortly.

The crashes are sort of all over the place though, it isn't a singular thing. I've reported a few crashes (most of them occurred during v257), but most of the bugs that I report are just completely ignored. Oh well.

Operating System: Windows 7 Ultimate 32-bit (6.1, Build 7601) Service Pack 1 (7601.win7sp1_gdr.140303-2144) Language: English (Regional Setting: English) System Manufacturer: eMachines System Model: EL1352G BIOS: Default System BIOS Processor: AMD Athlon II X2 220 Processor (2 CPUs), ~2.8GHz Memory: 4096MB RAM Available OS Memory: 3584MB RAM Card name: AMD Radeon HD 6670 Manufacturer: Advanced Micro Devices, Inc. Chip type: AMD Radeon Graphics Processor (0x6758) DAC type: Internal DAC(400MHz) Device Key: Enum\PCI\VEN_1002&DEV_6758&SUBSYS_E195174B&REV_00 Display Memory: 2551 MB Dedicated Memory: 1016 MB Shared Memory: 1535 MB

1: I absolutely hate the load times for the levels. I don't have a high-end computer, yes, but I can still play the game. However, the fact that I have to load all my characters into each map even when I enter a building in Dyrford make this absolutely soul-draining. This needs to change. Entering a house or the top floor of a building does not require a loading screen and I should be able to split my party when doing this. That was the IE way. Anything less is just not IE. 2: Combat elsewhere is locking out my party. I entered the Dyrford ruins through the tanner's back room and immediately, a "boar companion" was beset elsewhere on the screen. Not within my vision. Nowhere near me. This places my entire party in some locked-down status that forbids me from resting, exiting the level, and a bunch of other stuff that I can't be bothered to ennumerate right now. I understand the need for proper difficulty and forbidding "cheesing" from players, but this is bugged as all hell and really limits what players can do when playing the beta. The devs need to come up with a better way of doing this and an option to exit the combat state. 3: Constant crashes and unstable builds that make my game crash during loading/saving, etc and the reintroduction of bugs in the game where they previously did not exist. Everytime my game crashes, I lose the drive to play the game. At this point, I'm beginning to become concerned that the game will never be stable and that my backing this game was a terrible mistake. Whenever the game crashes, I think back to the incredibly high load times, the buggy mess, and the possibility of a crash mid-game. It's turned me off several times and I'd much rather play another game instead of Pillars. There are multiple other issues with the beta, but at this point, these three are seriously concerning and making this the worst gaming experience I've ever had. Yes, yes I know it's a beta. But at some point, I would expect that the gaming experience would start to improve. At this point, the base game without all additional content is difficult to enjoy. I am beginning to think that this is nothing like what an IE game would be.

Just wanted to say that the current glossary is great and very useful. I especially like the afflictions and injuries mechanic and I'm glad you put that up. The combat mechanics are also very useful and it would be nice to have those numbers up in the inverntory UI (see my other posts about the inventory UI). I also suspect that you guys are working on adding a feature where clicking certain words (like in item descriptiosn for example, accuracy is written in red), would take you to the particular glossary page, or perhaps show that information in a pop-up. The only issue I am having with it is that again it does not descirbe the "fatigue" mechanic and how this is derived. Fatigue as it relates to the athletics skill is fairly nebulous at this point. Anyone else with thoughts about the glossary can feel free to reply to this.

When I am in the inventory UI and I am hovering over the different stats (health, end, accy, etc) only the will defense will highlight (the text becomes slightly brighter). None of the other defenses or stats highlight if I hover above them.

When going into the Options Menu from the Main Screen and going under the language options, the selected option is not shown. There is only a black bar. If I click on the black bar, the options will show, but my selected option is not visible.

When I am in the inventory screen, I am trying to see the different changes as they occur with changing up the weapon sets. If I click on the weapon set II and then after a few seconds, I press on Weapon Set I, it will crash. crash dump uploaded 2014-10-27_201744.zip

Either the accuracy calculated under the inventory is incorrect, or it is being shown incorrectly, or I'm not calculating the accuracy correctly. Steps: I created a female godlike druid from rautai (hunter?) with a spear. The spear has a +5 accuracy bonus. I gave the spear to my orlan. The orlan has two weapons a hatchet and a short sword (both +4 accuracy). With spear and hatchet, my accuracies are: 44, 44 With short sword and hatchet, my accuracies are: 44, 44 This is incorrect as one accuracy should be better than the other as one is a +5 accuracy and the other +4. What am I missing here?

I tried using the fighter dwarf's helmet on the elf. It is still not fitting his head correctly. This has not been acknowledged since the last patch. Similarly, the hair and ears of the dwarves and orlan (respectively) are always sticking out of the back and sides of the helmet, respectively.

on the first map, there is a house north of where you start where there are two npcs in that house. there should only be one because the one of them says that the other dude is away and will be returning. the second dude is non-reactive when you click him. can't be arsed to be more specific than that.

just out the patch now and send in a hotfix later ;P

you're right. the biggest problem is the lack of visual feedback between idling and recovery while in combat. I don't know who's standing around getting hit and who's recovering from a spell/attack.

Wouldn't it have been easier to just make a lot of enemies resistant to ranged attacks? Like I said, "poor hack-job answer to that." But the mechanic can be interesting in combat.

I don't understand your question: Engagement was a mechanic in response solely to ranged attacks being OP. It's a poor hack-job answer to that, but as it stands on its own, I like engagement mechanics because if implemented correctly, it can really make for an interesting mechanic to play with. As for being "sticky" as I described it, it was because getting free hits while two combatants cross each other to get to the other side of the road is a terrible and bug-ridden implementation of the core idea. Who gets to decide who gets the AoO attack? How is the player supposed to (in a RTWP game) react fast enough to make informed attentive decisions and commands when things are flying past him? Especially when 6 different characters are fighting from 1-20 different moving targets on a board? Let's not talk about the obstructive FX that clutter up that whole battle and bugs that don't even let us see how it's *actually supposed* to work... now i'm rambling.

In Age of Empires 2, whenever you had too many workers and wanted to know who wasn't working, you had an idle worker button that told you who was just standing around. It would be nice if there was an idle status on your units that stated they weren't performing an action. This would be benefical in combat as well because many people play with AI off and sometimes your charcters are just standing around waiting for the next command but the player isn't aware that they're idle. By placing an idle icon on their portrait or to the side, players can immediately identify who's not performing an action and can focus on that character. Movement, attacking, casting, using an ability would all constitute as an action and not being idle. Stealth would not count (you can be stealthed and idle). The idle worker button in AOE2