Hormalakh

You can't tell me where I can and can't post. Disabling engagement is now my number 1 priority.

It's now more clear than ever that they are wasting more time and energy on UI, mechanics, AI on a poorly thought out design that does not work as hoped. It's time to kill the beast and turn our energies to more fruitful discussions. I think killing engagement will make the Poe combat much more fun and interesting.

Get rid of the engagement mechanic. It's too cheesy and broken. Stop wasting time with it.

When someone figures out how to mod out engagement mechanics, let me know. I'm willing to put up with the cheesy tactics of ie games of old without this terribly implemented mechanic.

I don't agree we don't need notes. If we are to be beta-testing we have to know what changes between builds just as good as the real QA team, if we are to be of help. Not giving us notes leaves me with the impression that no one takes beta testers seriously as someone who can help with the development. And if you ask me, a game that has been delayed twice because of development goals not reached in the assigned timeframe, is certainly a game that could use some free help from its community. If they have a QA team, they must have much more detailed notes on changes between builds. I'm not pretending I know better than them how to organize a team, so I'm sure their QA is working, I just don't know why don't we get the same grade of information as them. Overall, I don't think they are utilizing us as good as they could. You are of the incorrect impression that they value your opinion as much as the qa teams when it comes to detailed feedback. They really don't. As has been mentioned several times in these very forums, they are really appreciative of our overall ~*feels*~ as josh likes to say. This is more important to them than x minuscule bug or y bug.

The problem was that players were not thinking about skill use in the old system when upgrading their skills. The current solution (which is not really a solution) tries to rectify this. As I mentioned before, player choice,I believe, had to do with lack of clear input to them about what each point in the skill meant, i.e. What does one more point in x skill give the player - in terms of factual, tangible benefit? The remedy shouldn't have been a clunky new talent-skill system. It should have been more information for players to make informed decisions. However, you can buy skills as a talent in the new system. I think it's just that these skill points are not balanced against a much more interesting talent pool.

any update to the beta doesn't really need notes. the game isn't finished so everything should technically be work in progress. technically. the notes you expect are from complete games which ahve been published. it's more appropriate to compare betas to betas. many do it like poe.

One of the things that has been an issue is characters being behind walls and other occlusive objects (trees, pillars, etc). This, coupled with the lower angle of vision gives more opportunities for chracters to be visually "blocked." Other games solved this problem by either removing the blocking view (Fallout 2) whenever a character was there, or by making the object slightly transparent. Perhaps if this was implemented, it can go some distance in making the game more readable. ------------------ Similarly, perhaps the ground/grass needs some less contrast/noise to make it visible as justinian has mentioned. I think part of the problem is that it takes a long time to bake those maps again. Maybe that's why they're trying everything but changing the maps?

The voice-overs sound great. I like the portraits and the item graphics. Your graphics artists are undoubtedly talented and it shows. I'm glad that the conclusions you reached via your internal play-test was similar to the beta players concerns. Let's see some good come out of it now. I will hold my comments on the beta backer until I have played it and will comment in threads as appropriate. As always, all the best to your team - it's difficult making everyone happy and I've had my share of frustrations with the beta, but here's to a strong finish and a good game. All the best and happy thanksgiving.

It seems like Pillars of Eternity has too many designers and not enough coders/programmers. Having more ideas than people who can script them (not to mention the slow turn-arounds on bug fixes, monthly updates for example) is likely a symptom of that problem. For your next game (if we ever get there), you should think about readjusting your skill pool. In the meantime, don't anger your coders.

hence the bug. getting back to the original discussion: the lmb and rmb can (almost) be done as rumsteak wants it. It can also be done (almost) as Sensuki wants it. The other stuff, not so much. Let's talk about the other stuff now.

I have attached an image for the QA team. What I want (and currently cannot occur) is in red. Ultimately, formation rotate should only NOT be able to be bound to the same mouse button as select (click and drag functionality) and move. One way to implement the idea is to use action hierarchies and context sensitivity. Hierarchy would be as follows: Attack Select Interact Move/Rotate

For those interested. I did "draw" a picture. This will allow you to use the RMB as the move/attack/interact command while LMB performs the select command. The only issue right now is that I cannot use formation rotate (in red) with the rest. As soon as they fix that problem, move will be a moot command and formation rotate will take its place because formation rotate inherently does that. Then I will just unassign move as a command.

so what you're saying is that you didn't actually try out what i'm talking about. whereas i double and triple checked it before posting.

No it's not. The move command is inherent to rotation formation. There are no commands inherent to a mouse button. PERIOD. Again, there are no commands inherent to EITHER mouse button. If you unbind all your mouse buttons in the option menu. They DO NOTHING. Stop misinforming everyone. The reason that you can bind something else to it is specifically the argument I'm making. For the following commands: MOVE ATTACK INTERACT SELECT you can have the same mouse button for them. You CANNOT HAVE FORMATION ROTATE have the same mouse button for it. The only two buttons that cannot be on the same mouse button should be formation rotate and select as these both require a click and hold and then drag. That should be the only restriction. Otherwise, all other commands should work when bound to the same mouse button as they should be context sensitive. If move/attack/rotation formation/interact are all on the same mouse button it should work like this: If you give an command on the ground with rotation formation, you should be able to rotate your formation. If you give the command on an enemy it should attack. If you give the command on an object it should interact. CONTEXT SENSITIVE. NOT INHERENT TO A MOUSE BUTTON. D'UH. Formation rotation is just a move command that is draggable (click and hold). This is a bug and it should work differently.

Wow you're either trolling me hard or are actually this dense. Do this: Bind move/interact/select/attack to LMB (mouse0). Unbind formation rotate completely. Bind cancel action to RMB (mouse1). There. What you want has happened. Move is NOT INHERENT to the RMB. Formation rotation HAS A MOVE COMMAND inherent to it. There is nothing inherent to the mouse buttons. stop wasting my time and giving out incorrect information. Supposedly you've been playing this game that long. The least you could do is verify your information before putting it out here and confusing everyone else. The very issue I'm asking them to fix is to not make formation rotation have to be a separate command (even though a middle mouse button could easily take care of this problem). That is just part of the code and they can get rid of that restriction by removing that line. Do you need me to draw you a picture?

This has nothing to do with cancel. This has to do with the ability to bind multiple commands to the button where formation rotation is bound. I do not care about move or cancel or anything else that you are talking about - do not confuse the issues here and kindly bring your issues up in a separate thread.

Nobody is talking about cancel. Learn to read. I specifically am asking for the ability to bind multiple commands to the button where formation rotation is being bound to. Everything else is what you want. And I do not care what you want.

I'm sorry I wasn't clear: I meant tricky to code. It might require an overhaul of how their buttons and abilities are set up. Also I'm not sure how many players would like that or be able to understand that scheme. Anyway....my two cents.

As mentioned in the other post: You obviously haven't messed with the predefined keys for movement/attack/formation rotation. If you had, you would realize that rotation formation is NOT inbuilt and that you can select a button for rotation formation. Currently, that button is right mouseclick. It has nothing to do with holding the mouse button or anything like that. It's set as RMB and that's it. Similarly selection is SET as the LMB and can be changed to the Right mouse button. The only issue is that while selection/movement/attack/interact can be issued the same mouse button, formation rotation has to have its own mouse button. I believe this is a bug as it should be possible to use any of the other commands (outside of selection) with rotation formation, as the way you select may (though not necessary) require to hold a mouse button. If anything, only formation rotation and selection should be different mouse buttons as these two buttons work (though selection can also work with single-clicks) when being held.

1- I'm sorry. Who are you again? Why do you matter exactly? 2- You obviously haven't messed with the predefined keys for movement/attack/formation rotation. If you had, you would realize that rotation formation is NOT inbuilt and that you can select a button for rotation formation. Currently, that button is right mouseclick. It has nothing to do with holding the mouse button or anything like that. It's set as RMB and that's it. Similarly selection is SET as the LMB and can be changed to the Right mouse button. The only issue is that while selection/movement/attack/interact can be issued the same mouse button, formation rotation has to have its own mouse button.

So having finally played with the hotkeys, I'd say they're better than nothing, but they weren't exactly what I was hoping to see. I would much rather have context sensitive hotkeys similar to how DotA2's work for invoker and some of the more complex heroes. I want to bind the same four keys to multiple spells based on the hierarchy of the button. So for example, let's say my frimoire has these spells per level (with their associated hotkey): level 1: chill fog (Q), minoletta's minor missles (W), slicken (E), fan of flames ® level 2: combusting wounds (Q), ray of fire (W), rolling flame (E), necrotic lance® level 3: noxious burst (Q). I would set a hot key for each spell and I could set a hot key (same one) for the spell level to cast. So leve l1 is Q level 2 is W, level 3 is E. If I want chill fog I would hit QQ. Minoletta's QW. Slicker QE. If I want noxious burst then it would be EQ. Combusting wounds is WQ. etc etc This of course would be most useful to the multiple spells classes like druids, chanters, priests, wizards. However I can see all classes having their abilities categorized into smaller subsections so that the control scheme can be used for all classes. For example, fighter abilies or barbarian abilities can be categorized into per rest (Q), per encounter (W), etc etc. Of course, if a player wants to just bind a single ability, they can do the same thing, by just picking that hotkey. Context-sensitivity. Bugs galore if implemented and would take a good bit of time to get right. But it seems like its too late for something like this design. One can still hope.

Currently formation rotate will not allow itself to be binded along with other buttons. However, move, interact, and attack can all be binded to the same button/key. This should not be the case. I want to rebind my keys so that my left button only selects characters, while my right button moves them, issues an attack command, and interacts with items, however I want it so that when I click and hold my right mouse button, I can rotate my formation. This is because formation rotation automatically makes the characters move already (making the move action useless, basically). This action (formation rotation) should be context sensitive. If I have a bunch of characters selected and I want to move them, I just quickly click. If I want to rotate formation, I click and hold. If I want to attack, I click on top of an enemy. Please fix this. I hate the current control scheme and it has caused quite a bit of issues. See here for more information. http://forums.obsidian.net/topic/69390-yet-another-ui-suggestions-thread/

All of what we are arguing here is moot. You can rebind your control set up for whichever system you want. Unfortunately, however, the wise developers made formation rotation only bindable to a single button so it makes it difficult to have your move, interact, attack, and formation rotation on the same button. Currently both left and right click move the characters (I'm assuming that's not how IE had it, Sensuki, since you love IE's control scheme so much?). And I believe only left click attacks and interacts.

Except IE games have been out of style for decades. New control schemes have taken over and players have gotten used to that. IT's like what rumsteak was saying about the next button being on the bottom right. Nowadays, everyone right clicks to move/action. Left clicks to select. All games do this. Who cares what a old system did when everyone else is now used to the new one.