ushas

(BBv435 linux) 3) Possible confusion when subtracting damage from Endurance and Health integer variables: [Description] If I understand it properly - when being hit, the damage extracted from the Endurance and Health should be equal? Well that's probably in a way true, but similarly as in the issue 2, sometimes there is a difference by one. In this case I'm not talking about the same variable, but about an extraction of the same amount of damage from two variables. On screen it is done in an integer space. The issue: Sometimes the damage taken is not the same when comparing Endurance and Health decreases in game. And the integer damage taken is not always the same as presented by combat log (or the floating damage number). Lets demonstrate it again on BB Fighter with the Fine Hide armor. Several tries are probably needed to replicate. Attacking by piercing weapon (a fine quality spear). 19.5 - DR:8.3 = 11.2 Endurance: -12 Health : -11 Or with a morningstar (crushing) 12.4 - DR:7.0 = 5.4 Endurance: -6 Health : -5 Note: In all cases, in the beginning, the BB fighter has full health and endurance bars. [Expected behaviour] Seeing the Health and Endurance as integers in game, one would expect that the damage taken is the same as presented in the combat log, and that both their decreases are equal integers. [Comments and speculations] The difference between Health and Endurance behavior is probably a feature of the rounding in game. Again, both variables aren't truly whole numbers. I will try to present this on BB fighter, below. To my limited knowledge the game calculates the damage taken like this: Assumptions: Fighter lvl 4 with 18 CON (24% health increase) -> Endurance (E) = (42 + 14*3)*1.24 = 104.16; Health (H) = 5*E = 520.80. The rounding of health variables is slightly different, it's something like floor(E+0.9), so it rounds up. In the case of BB fighter -- Endurance:105, Health:521. Therefore in game the player sees info like this: Here I made also assumptions about the rounding of the damage info, but the real game behavior is prehaps similar(?). What is interesting is the highlighted part of the table, where we can see what may confuse the player. Apart of damage done inequality of the combat log and the floating number, for some damage ranges there will be different numbers subtracted from Endurance and Health compare to each other, or compare to the damage done info. I see this as one of the features of rounding tendency of the game. Some possible not-easy solutions (which solve the other issues and bugs as well): a) Show all the numbers as they are (eg. the first table) in game, as already suggested several times. b) Accommodate rounding to integer numbers earlier in calculations. For example: - use whole numbers for DR sybtypes (eg. 4.3 -> 4) (so you don't need to deal with descriptions of armors) - round the weapon/ability damage after applying all the multipliers (eg. quality enchantments, % from Might, etc.), aka 15.57 -> 16 - the Endurance of the character will be rounded right after the level up (eg. E = 104.16 -> 105, H = 5*E = 525). --> Then the combat log tooltip formula will look like 16 - DR:4 = 12 (this will be the real calculation already) --> And therefore, the real damage taken will work as an integer calculation too: E = 105 - 16 = 89; H = 525 - 16 = 509. Not knowing whole game mechanics and the source code, I guess this will have it's own issues. So please take suggestions just as a discussion on the quest to seek possible solutions...

(BBv435 linux) 2) Red floating damage numbers and the combat log integers are sometimes not equal: [Description] In a mouse-over tooltip formula in the combat log, a damage calculation (subtraction of DR) is shown in decimal numbers. The same resulting damage info is presented as an integer in the normal combat log mode, and as well as a red floating damage number on a game screen. The issue: The floating damage number is sometimes lower by one than the corresponding integer in the combat log. To imagine how to reproduce the problem, see pictures below. However, the damage numbers will not always end up different, so it may take several tries. BB Priest attacking the BB Fighter with his own morningstar (a fine quality), the targer wears Hide armor: 19.9 - DR:5.0 = 14.9 Crush Combat log: 15 Floating num.: 14 The same weapon, this time with Fine Hide armor: 16.6 - DR:7.0 = 9.6 Crush Combat log: 10 Floating num.: 9 Freeze damage with Fine Hide Armor: 13.2 - DR:8.3 = 5.0 Combat log: 5 Floating num.: 4 -> The floating damage number is the wrong one? [Expected behaviour] Simply to see the same damage values in all places. I would advice to show numbers in all their decimal glory everywhere to prevent player's confusion. Or at least in the normal combat log. And then of course, correct the rounding for the floating damage value, in case this report is right. Also simultaneously, there is a possibility for an inequality of an integer subtraction from the health bar (see the issue num. 3). [Comments and speculations] It feels to me that the floating damage numbers are being rounded down as floor(D - 0.1) or floor(D), and the combat log integers like floor(D + 0.4) or floor(D + 0.5). I'm not sure, as the behavior wasn't consistent entirely (eg. once it was 9.5->9 and the second time 9.5->10). The reason may be connected to the fact that combat log decimal numbers are rounded too (see the bug num. 4).

(BBv435 linux) 1) In window descriptions of quality armors show different subtype DR values compare to other sources of the information: [Description] There are several places reporting an armor's Damage Reduction (DR) profile. In most cases we see integers, but the actual numbers (according to the combat log) are decimals (aka 6.0, 6.4). That is especially important in case of the armor's specific DR subtypes (slash, crush, pierce, burn...), which have noninteger values (aka 6.4). The issue: In window descriptions of most of the armors with a quality enchantment (fine|exceptional|superb) show different DR subtype values compare to other sources of the information. This is already reported. For further details (and a screenshot) refer here: http://forums.obsidian.net/topic/70345-wrong-integer-values-of-dr-subtypes-in-descriptions-of-quality-armors-compare-to-the-character-panel-info/ As an example, I would like to pinpoint this for a Fine Hide armor: Normal Hide armor: Description window: DR: 5 (Pierce:6, Freeze:6, Corrode:3 ) Character panel : DR: 5 (Pierce:6, Freeze:6, Corrode:3 ) Mouse-over tooltip : DR: 5 (Pierce:6, Freeze:6, Corrode:3 ) Combat log : DR: 5.0 (Pierce:6.3, Freeze:6.3, Corrode:2.5) Fine Hide armor: Description window: DR: 7 (Pierce:9, Freeze:9, Corrode:4 ) Character panel : DR: 7 (Pierce:8, Freeze:8, Corrode:5 ) Mouse-over tooltip : DR: 7 (Pierce:8, Freeze:8, Corrode:5 ) Combat log : DR: 7.0 (Pierce:8.3, Freeze:8.3, Corrode:4.5) -> Item's description window shows probably wrong numbers... Notes: - Description window is accessible by a right-click on the respective armor item; - Character panel shows DR numbers after equiping the armor; - Mouse-over tootltip is displayed after hovering the pointer over character's doll in the game window; - Combat log values are taken from the the mouse-over tooltip formula, after being successfully attacked by the corresponding DR subtype. [Expected behaviour] I would expect either to show real numbers of DR and DR subtypes in all places, or at least use the same rounding mechanism, if that is the issue. [Comments and speculations] Perhaps, the description window is using different rounding function after a quality enchantment? While testing armors with proofing enchantments, the issue was not detected. (for the applied DR subtype)

(BBv435 linux) This bug report will try to bring several issues and feedback to them together. The reason is: I think they are connected, and the connection winner is a rounding function. Please feel free to correct me in case of being wrong, and separate the bug reports. All the problems, which are reported below, stand on it's own, even if my understanding is wrong. [Overall description] For the player's convenience, the game shows combat variables, like damage, Damage Reduction (DR) of armors, Endurance, Health, etc., on several places as integer numbers. That is great and useful, of course. The fun starts, when sometimes the integer numbers are not equal, even though they represent the same thing. The common property of the issues is, that the difference is 1; (or 0.1 in case of decimal damage numbers in the combat log formula, see the bug report num. 4). The difference is not always an error, as the Endurance/Health behaviour (see num. 3) is probably a feature. But regardless of features and errors, in the end, the player can be confused by delivered information. And I suppose that is not a goal of the game's communication. List of the problems: 1) In window descriptions of quality armors show different subtype DR values compare to other sources of the information; 2) Red floating damage numbers and the combat log integers are sometimes not equal; 3) Possible confusion when subtracting damage from Endurance and Health integer variables; 4) From time to time, the combat log formula shows wrong calculation of the difference between weapon damage and the corresponding DR. For individual details and discussion see subsequent posts. [Overall Expected Behaviour] The information provided to the player should be consistently presented by UI. To minimize the player's confusion, the wrongly estimated (rounded?) integers should be corrected to fit the right ones. But naturally, I would prefer if the exact numbers are shown in all places, if possible. [speculations] The common differences by one, and decimal info from the combat log formula, indicate that many of the combat variables are perhaps used as floats (?). Thus the game is displaying the rounded results. My speculation is, that all the calculations are probably done correctly in the real numbers space in the code. But the translation into the rounded decimals or integers, which are shown on screen, is not executed properly in several troubled places. -> Possible rounding errors after add or subtract operations? Different rounding functions used, and/or used in incorrect places? There are probably other instances of similar inconsistencies as the listed ones. But besides the obvious errors, I don't know whether it's useful to seek them out further. As some of the confusing information can be connected to the overall design decisions.

[setup: linux build of BBv435, although the same issue was detected while playing windows version of BBv392/BBv435 under wine in linux] [Description of the issue:] For all armors with a quality enhancement (fine|exception|superb), the DR subtype numbers (slash,crush,pierce,burn,...), which are listed in the right-click accessible description, are in the most cases off compare to the same info on the character panel, after equipping the quality armor. When tested by being attacked, all the tested numbers of the troubled DR subtypes are in the format of decimal numbers in the combat log. -> So the integers on the character panel and in the description are probably rounded from decimal numbers (eg. 6.5->7, 6.3->6)? However, in case of quality armors the values in the description window are rounded wrongly. Did a test for a few armors. For example: Normal Hide armor: Description window: DR: 5 (Pierce:6, Freeze:6, Corrode:3 ) Character panel : DR: 5 (Pierce:6, Freeze:6, Corrode:3 ) Combat log : DR: 5.0 (Pierce:6.3, Freeze:6.3, Corrode:2.5) Fine Hide armor: Description window: DR: 7 (Pierce:9, Freeze:9, Corrode:4 ) Character panel : DR: 7 (Pierce:8, Freeze:8, Corrode:5 ) Combat log : DR: 7.0 (Pierce:8.3, Freeze:8.3, Corrode:4.5) Combat log values are taken from the tooltip formula, after being successfully attacked by the corresponding DR subtype. The picture below shows the fine version of the item: Didn't had time to test all the armors in the combat to get the correct numbers. However at least, I made a table (see attachment), where the wrongly listed DR subtypes for individual quality armors are highlighted in the red. For many of these armors, the description inconsistencies are checked in the base game. Afterwards, I used Bester's IE mod and the console command AddItem to take a look at other accessible armors. And the result is, that when an armor had a Fine|Exceptional|Superb property, it usually came with the same issue. Nevertheless, not to spoil the special items, the table contains only basic armors and their quality enhancements. armorsBBv435_base.pdf [Expected behaviour] Expected behaviour would be, that all the armor DR values would be the same. I would prefer myself, if the correct decimal numbers (provided the combat log is right) are shown in all instance. And if not possible (easy readable integers?), at least correct the issue of inconsistently shown integer values for the quality armors. (used a wrong rounding function?) [additional comments] -- only exceptions to the quality issue are robe armors, because the base item (Robe) does not alter any DR subtype (It's flat 3 Base DR); and Fine Scale Armors (Exceptional ones still show the issue). -- in case of crafting, I have tried to add Fine quality to the basic Leather Armor and Padded Armor -> resulting items had the same wrong numbers as the bought ones. -- proofing and attribute enhancements are probably working right, but didn't check that in combat, only by equipping.

Tested with BB Priest on a linux build: [Description of the issue] For tested abilities (see below), which operate on a longer than close-range distance, there is an inconsistent behaviour of the character AI (an actual movement) in comparison to the spellcasting cursor change to contain a footprint (to indicate a need of movement). -> So the character can actually fire a spell on a slightly larger distance than the cursor indicates. [DETAILED list of steps to reproduce the issue AND what to look for] 1) Choose a BB Priest and some distance spell; tested spells: -- AoE spells: Instill Doubth, Divine Terror, Restore Light Endurance -- single target: Divine Mark, Halt, Barbs of Condemnation 2) Point a targeting cursor barely on/over the edge of the spell distance (just where the cursor changes to contain a footprint); 3) Activate the spell; 4) And observe that the character didn't need to move from the original spot to fire the spell, despite of the icon indication... [Other remarks / Comments] Probably bug in the icon change? May be related to these issues: http://forums.obsidian.net/topic/69700-364-perception-and-spell-range-indicators/ http://forums.obsidian.net/topic/68536-wizard-running-to-point-blank-range-to-cast-spellsrange-icon-incorrect/?hl=distance&do=findComment&comment=1511154 Althrough, I can reproduce it consistently.

[Description of the issue] This is probably a linux issue? Cloaks/Capes don't fit character models. Tested on all BB party members + Orlan male (see picture below). Also possible not working on a Mac: http://forums.obsidian.net/topic/70226-435-discussion/?p=1565458 [DETAILED list of steps to reproduce the issue AND what to look for] -- in the linux (mac?) version of the game, put a cloak on any party member. [Expected behaviour] Cloaks/Capes should be scaled to all character models/armors appropriately.

(Character creation, linux version) [Description of the issue] Simple clothing and Aedyre clothing show graphical glitches on Orlan (resp. goodlike) males. Simple clothing shows glitches on elf male models too. See attached image. [DETAILED list of steps to reproduce the issue AND what to look for] 1) Start a new game; 2) Select a male, race Orlan or Elf; 3) Choose a Cipher class (+ Aedyr culture -- implicit); and/or in case of Orlan a Wizard/Monk class; 4) Graphical glitches should be visible on the character creation screen already. [Expected behaviour] Clothing should be without the glitches as for the other races.

[linux version] I have the same issue with any human or a goodlike human male choosing Cipher class (~Aedyr culture this time) --> this is probably an issue with a human male model + simple clothing?

[bBv435 fedora 21] Cyclopedia: *Missing cyclopedia 206* +-> *Missing cyclopedia 207* in description *Missing cyclopedia 210* +-> *Missing cyclopedia 211* in description *Missing cyclopedia 212* +-> *Missing cyclopedia 213* in description

+ *Missing guid 1882* in the description, see: http://forums.obsidian.net/topic/70229-first-435-bug-missing-string/ I confirm this on a linux version.

"Combat only" prevents one of the more glaring problems that existed in the IE games... Pre-buffing. Which besides being exasperating caused all sorts of balancing issues. Pre-buff parties were magnitudes more powerful than parties who went in unbuffed. That being said, don't see any reason for modal abilities to be combat only. Wanted to ask too, why so strict combat non-combat distinction, when there is no visible change of the game flow (eg. as in case of switching to turn-based combat)... I hope the pre-buffing issue is not the only reason. Because that would seem to me as an exaggerated precaution. For example, like a situation where the government finds out, that the terrorist who blew out a train was an immigrant -> so logically decide to proceed by completely closing all borders...

Thanks for the beta and info! How should we proceed for these "NEEDS VERIFICATION" points? Post here; Post individual bug reports in Bugs and Support subforum in case it's not working; Or make there one global "NEEDS VERIFICATION v435" thread, where anybody who can, will verify the points?...

Well, they are most probably not doing "Rare benefits are the best/only benefits", or I guess, at least there will be other ways around. So I don't know what is the issue...

Well there is always a limit. In a hypothetical case, if your accuracy is high enough to often score a critical hit to the enemy, but his high DT brings damage to the minimum -- wouldn't you consider the trade off? I guess, If the overall damage numbers are lowered now, this could be more interesting. But that's pretty much a speculation, as I know nothing about a balance of the next BB...

Firstly, thank you Matt for reaching out! In case you are still around, I would be interested in two main questions. However, not knowing whether you can answer them. 1) Ranges of abilities a) Is it true, that a range percentage bonus/penalty is removed from the attribute system as well? (in BBv392 it is +5% per point in Perception above 10). If yes, can you share the reasons for the decision? b) Are there any other means to boost the range of abilities (talents, items)? c) How do you in QA feel about a range indication from tactical perspective of a combat in the new build? For example, do you prefer to move party members to the appropriate range manually? Context: In current Beta v392, an icon of the spell cursor contains a foot to indicate that the game will firstly move the character closer to the target, before starting to use the chosen ability. However, beside a close range stuff, as a newcomer to the game, I don't have yet a sence of the risk for letting the game to do it for me (eg. how far a character has to move --> thus how much time will be wasted, and whether he runs into a greater danger...). 2) Hostile fauna/flora of the wilderness How is an overall feel about hostility variation of natural inhabitants across wilderness areas? (eg. full game versus BB) If needed to be more specific: Has a party various means in say whether to wipe out animals while exploring (eg. a different hostility behaviour, for example not hostile till we closely approach a nest)? Or are there other possibilities than high enough stealth to avoid the combat (eg. bug repellents, calming animals by survival skill, etc)?

In BBv392, there is a check for a skill level 11 or 12 (individual). It may help as a shotcut, but you can go around. So extrapolating, I guess in the final game a really high skill may mean an easier life in some instances, but probably not having it will not result in a dead end... (however, It would be really neat to have some no matter how small stuff only accessible with a highly specific setup)

You are right. Thanks. I misread attributes with abilities, and that other issue multiplicates granted abilities on the action bar. Ok, unfortunately so far I can play BB under wine in linux and forgot that it's not sensible for bug reporting. Can any of you playing on win or mac post savefile and list of steps to reproduce the permanent stat boost? Maybe it's better to wait for an upcoming BB version with that...

This thread is obviously related to the already recognized issue: http://forums.obsidian.net/topic/69998-392-guildmaster-staff-bug/

Good points! I would like to add for the mod support It may be even helpful to communicate future updates in advance. For example, when the game ships, posting and then updating the list of features planned for next paches may prevent possible work dupplication, in case modders and developers plan to implement the same stuff.

Having Draken's den resting buff as well, didn't know about the correlation. I thing it helped me to rest in different room to unpermanent it. Nevertheless I made and ate Ixamitl Ricepan during the Draken's den buff time. In crafting menu it is listed +50 PER and +50 CON instant over 150 sec (and +5 max endurance). Eating it (from quick items menu) works interestingly: After consumation, next to portrait tooltip shows +5 max endurance and +60 PER and CON over 180sec (probably thanks one point in survival?). PER and CON attributes are slowly raised during the buff time. And after that the buff stays permanent, as Sock mentioned. But Ixamitl magic doesn't stop here:) This superfood meal is additive to itself. As it doesn't disappear after eating, you can easily create superhuman. If I click on CON or PER attribute name during the effect of the Ixamitl Ricepan, it lists +1 buff. So I guess that is an intended effect? Should we test other foods and crafting recipes?

Thanks Tin Cain for the update! As a Sad Panda and others mentioned, it's logical, that crafting takes some time (I guess from several game minutes eg. ~instant, up to days...). It's one of the resources we are investing in (skills, money, recipes, ingredients, contacts, time to reach resources and places and time to craft, etc.) and contributes to crafting as a tactical choice... With this in mind, I can imagine if the NPC (or more NPCs when there is some collaborative recipes) is going to craft something more time consuming, the party can decide: (a) to wait during that game period (so from the player's perspective time is ~instant, or connect resting with cooking etc.); (b) or the party can left him (them) and do actively other stuff in the meantime and come back later... --> so it actually means temporary party splitting in case the crafter is party NPC (well if the PC wants to craft and story is being told from his perspective, it can be tricky -- so maybe only wait and rest option in this case?) On the other hand, It's understandable when you decide to make it game-time-instant for simplicity, eg. if you are inventing some time sensitive stories (quests if you must:)) and therefore you don't want to limit players even more by crafting times; And again what about a difficulty settings? Eg. on easy almost all the crafting is instant even in game time (except some story driven artifacts and crafting events), and on hard it will actually take some game time, so the player in the end cannot craft everything ahead. Some nice ideas: To more extend, the party actually shapes the world by selling "howknow" (generally, strategic information) to somebody... Personalization by colors... This are a few of many "crafting--story/lore connection" requests. Personally I support thinking among these lines, there should be limit what the party may craft easily -- a legendary and unique things should be crafted be unique specialists (and specialist teams, what about having whole scientific orders addicted to some craft?) and obtained by experiencing something special (quest for glory, sacrifice, rituals, legendary history, visiting unique places, nations-shape decision, famous owner...). Having crafting education (skills) among party members can add to the story by more understanding the techniques, decipher recipes, having contacts (getting hints who to consult and to ask for help with the craft), contribute as a assistants; and overally add possibilities how to to solve some issues (quests)... Aside to story options, I think there is space for normal effective crafting/enhancement/alchemy/cooking by party members which may be creative and personalized but not overpowered, altogether with that special crafting as mentioned above (and as in IE games). And in the end, I would like to ask to bear in mind that crafting is popular from the modding perspective. So it would be great if you at least try to make it as much easy as possible for modders to enhance and expand (or simplify) it, among the solid crafting basis in the game of course. -u

PS Ad*: Except other physically limiting resources (eg. amount of food and the weight limit), I find the injures/fatigue mechanism as proposed by others beeing elegant ideas. If implemented to the both extremes (eg. so we feel fatigue too if we rest too much -- doesn't have party of spoilt lazy brats a bad morale and low stamina? ), we can eventually get rid of artifical hard limits like the one rest per 24h (or limit to initiate a rest only during night hours; or one rest per dungeon etc.). I can imagine fatigue (together with the management of the food resources) as a part of the difficulty settings (or it could be one of the difficulty switches). -------------------------------- Just an example (let's assume that players generally want to rest): On higher difficulty settings: (type/quality of the area may contribute to the values and possibility to rest) (a) not having rest: -- after 48h fatigue factor will rise to something like f~50%, party members complaining; -- after 72h f~75% + casually story driven hallucinations? (microsleep, let sleep depraved heroes experience something special;)), -- after 96h may fall unconscious, so in the end, game force you to rest, or party members may force you earlier; (yes I know people can endure even 11 days: https://www.scientificamerican.com/article.cfm?id=how-long-can-humans-stay) (b) too much rest: -- if 2x in 24h -> f~30% (but eventually prior injuries may lower factor); party members complaining (about both extremes); you or other companions can have nightmares (=not effective sleep); if to some extend logical having a higher probability of weather & ambush events etc...; On normal settings (a lower sleep deprivation): (a) no rest: 48h f~20% and 72h f~40% etc.; (b) too much rest: 2x in 24h f~15%... On easy settings: ...do not use the fatigue factor (f==0%) -------------------------- u

Hi, a nice discussion:) So we are going to have a rest mechanic in the game (what about a resting-event image? and a wait mechanism?). Players will always complain, if it's too limited/forced/boring... Maybe we look at it for the most part as some mechanical construct, as an obstacle to make the game more challenging and a little more realistic. But it is part of the story too (what about party members' feelings?). Just for fun, an example follows. I haven't thought it through, mainly it's inspired by others (sorry for no citing, there are a lots of interesting posts in both threads). And as a not native speaker, I really apologize for wall of mess... ------------------------------------------------------ So let's assume we have a limit -- one rest per 24h (or other limit with diff. mechanism or a story tool*). In addition, if implemented in game, during each rest or a specific period of time, the party will consume specific amount of resources -- water + food + healing stuff; And if possible, refill the resources -- resting/travel near water sources, buying, hunting, picking and stealing possibilities (could be tied to some skills, and made partly automatic or so). If possible I would let players try to rest everywhere -- but with that consequences and some story outcomes -- with interesting events happen (why not some minor scripted-events on the rest image?) and with possible changes in the time-sensitive stories/areas/relationships (events not always have to be triggered, or no means to be almost completely random; and I don't see reason to use only those which will act as some sort of punishments/restrictions). In case of quests and stories and party members -- it could be an addition to the story/personality depth/logic and an alternative to resolve some issues (and I can imagine some nice easter eggs:)). In other words I wouldn't fight against an idea to make it fully integrated part of the story and the world itself. However, lets it be as much as possible an optional part of the game (players decide within limits when a and where to sleep). For simplicity, areas could be divided into several types (eg. your home, inns and NPC houses, streets, main roads, more dangerous areas)**. Events would be triggered/resolved by your decision to rest there (eg. in the neighborhood of something; resting screen as a scripted-event image?). Skills of party members may play a role. And the party composition itself (all cotravellers) is important... However, it all depends whether we have flow of time and possibly night/day distinction; and everything really depends on the developers:). In the end, if we have limited number of places where it's possible to sleep, then from the story perspective, it gives developers a lot more power to make the resting mechanism something, which is even more story/background/quests-related. And for our parties during resting -- well, when it's natural to get to know each other, discuss main events/quests and what to do next? ...or just share stories (eg. lore and exchange the past adventures before the joining), witness relationships evolvement, hints of secrets etc.?... When implemented well, the resting mechanism could be used to add more life to the party and be a natural addition to the story depth. So just before sleeping, you may want to decide to speak with others (in case you haven't done it yet during a day or there are more possibilities)... -- choose what to do before rest in the dialog-like menu on the resting screen/image? (some possibilities mentioned above) -- and/or as the story teller the game may just tell you on this screen whats going on (and what was the outcome), eg. what you see/hear/feel/taste/sence/smell; and eventually that you told others something (if you wanted to) and how they react... -- could be connected with the diary? -- generally I can imagine some skills-based events. -- more realistically, party members want to contribute to the decisions having something to do with the resting (may ask you to rest or not to rest, want to establish a watch etc.)... ----------------------------------------- So the point is -- and of course it's just subjective opinion -- if given more story-like reasons (~sensitive events + visually and by telling highlited areas, "looks like a good place to rest", getting some interesting details/info during the rest event itself etc.) -- players would be more willing to submit to the established resting spacetime rules (hard and/or soft limits) without too much outer force pressure feelings... Personaly, during the Quest for Glory II, every evening I have found myself back at the inn to eat and sleep just because of the possibility to share the midnight tea with Shameen and Shema and to exchange short stories (and see the dance:)) u

Greetings, as a linux backer with dislike of DRM in any form, nowadays I would support eg. tarballs and both (or any) listed options -- Desura and Humble Bundle store on your page, both having its pros. If you can maintain all the possibilities (GOG, Steam, Desura, HB...), that would be great. On Desura, users can vote, write a review or a comment, add a mod, and so on. You have another way to reach an audience. From my personal experience, having Dungeons of Dredmor too and few other games from Desura (fedora dist.) -- you don't need VM to install games, only have to register and then download a purchased product eg. as a tarball from the page. If installed/updated through the client you don't need it for the launch (so no another layer?), and you can move installation folder (which probably look the same) anywhere else and play from there... So maybe any form of DRM in connection to the VM is on the developers decision? A probably "desura" comment on ModDB: http://www.moddb.com/forum/thread/is-desura-really-a-complete-drm-free From the services point of view, I heard about some time delays with patch releases compare to the Steam. Sometimes for users it's not easy to distinguish whether an individual game is completelly DRM free. There are some rumors about a new version of the web store, so they may address this issue in the future... Or I guess you may clarify the DRM free info in the summary tab. In time of release, personally I don't have problem to wait a little longer for prefered distr. channel, if needed. Or will do some testing of installation if you ask us. One of the goals is the mod support (this and the linux version made me and maybe some others succumb to the Eternity). Do you plan this support with multiplatformity in mind -- eg. having easily editable/readable file-formats for everybody, or maybe in future if it occures to you to release some tools, would you make it multiplatform? It would be great too if anybody could download any mod and easily add it to the game regardless the platform (differ only by the installation folder paths). Sorry, if beeing offtopic too much. Thank you for the possibility to voice opinions!