Jump to content

AnorZaken

Members
  • Content Count

    19
  • Joined

  • Last visited

Community Reputation

15 Good

About AnorZaken

  • Rank
    (1) Prestidigitator

Badges

  • Pillars of Eternity Backer Badge
  • Deadfire Backer Badge
  • Deadfire Fig Backer
  1. Well, Stylish is a plugin that allows you to inject css into the page you are viewing. (The browser always re-renders the page whenever the page-content changes.) Css-document is simply a collection of style descriptions - it contains instructions such as "make all links inside a table green and font x" or "make the background colour of divs that matches this filter gray and 20% transparant", etc. The styles you can download from userstyles.org for plugins such as Stylish are simply css + an url filter that tells the plugin when (on which sites) to apply this css. I say styles, not "scripts", because css can't contain anything executable, just data. The only executable part is the plugin that manages the styles. For example the style above is very simple and short, this is the entirety of it: First line is the url filter. (In this case it's very simple, but it can be a regular expression if we desire a more complicated filter.) The rest applies this css-rule, to all sites with a matching url, i.e. to all of obsidian's forum: "On every other line in a code view (li.L1, li.L3 etc.) set the background color to gray, 90% transparent." (The above can also be seen by pressing the Show CSS button on the style's page.) As for how to revert it, Stylish, the plugin, has a Manage Styles page that lets you see, toggle, uninstall, and update all your styles. Edit: Now I can already see your next question coming: How does "li.L1" (etc.) translate to something so specific? Well the answer is quite simpel actually: it is site-specific - it is the unique way in which the guy or girl that wrote the forum software, used by obsidian, decided to name them. Elements in html often have little tags and stuff on them, added by the site designers, specifically so they can style them with ease and flexibility using css themselves. CSS was invented for the purpose of separating structure, content, and functionality (html+javascript), from visual style (css). It's a much more powerful and flexible solution since the site designer can reuse one css-style on multiple pages, and changing the css will update all those pages. Contrast this to editing each html-element by hand, which would be both time consuming and error prone.
  2. Not quite related, but since your css for alternating line color on code snippets is obviously borked when the forum is viewed in the dark theme, perhaps you should fix that too. So have a little looksies in https://forums.obsidian.net/public/style_css/prettify.css which has the offending line, line 40, and change it from this: /* Alternate shading for lines */ li.L1,li.L3,li.L5,li.L7,li.L9 {background-color: #f5f5f5; } to e.g this: /* Alternate shading for lines */ li.L1,li.L3,li.L5,li.L7,li.L9 {background-color: rgba(128, 128, 128, 0.1)} ...or if you're not the web-admin, you can install my user-style to the same effect, from here: https://userstyles.org/styles/154381/alternating-code-line-color-fix-for-obsidian-forum (This looks good even if you are using the forum's white theme, so should just replace the current css really!) Here's a preview of what that looks like: and if you prefer the white theme, then it looks like this: .Still looking good. If one of the moderators could push this to the webadmin that would be great.
  3. [[ If you're having trouble reading the code below, because it looks horrible, look at the next post for how to fix the css! ]] Ok I made my own workaround for now by modifying the game files. In file PillarsOfEternity_Data\data\conversations\03_defiance_bay_ondra_gift\03_cv_aefre.conversation I made the following changes.... Go to the conditionals on line 1429, then add the following OR clause, such that you go from this: <Conditionals> <Operator>And</Operator> <Components> <ExpressionComponent xsi:type="ConditionalCall"> <Data> <FullName>Boolean IsQuestOnNode(String, Int32)</FullName> <Parameters> <string>assets/data/quests/03_defiance_bay_ondras_gift/03_qst_the_taint.quest</string> <string>2</string> </Parameters> </Data> <Not>false</Not> <Operator>Or</Operator> </ExpressionComponent> </Components> </Conditionals> to this: <Conditionals> <Operator>And</Operator> <Components> <ExpressionComponent xsi:type="ConditionalCall"> <Data> <FullName>Boolean IsQuestOnNode(String, Int32)</FullName> <Parameters> <string>assets/data/quests/03_defiance_bay_ondras_gift/03_qst_the_taint.quest</string> <string>2</string> </Parameters> </Data> <Not>false</Not> <Operator>Or</Operator> </ExpressionComponent> <ExpressionComponent xsi:type="ConditionalCall"> <Data> <FullName>Boolean IsQuestEventTriggered(String, Int32)</FullName> <Parameters> <string>Assets/Data/Quests/03_Defiance_Bay_Ondras_Gift/03_qst_the_taint.quest</string> <string>5</string> </Parameters> </Data> <Not>false</Not> <Operator>Or</Operator> </ExpressionComponent> </Components> </Conditionals> This edit will, when you talk to Aefre, enable the conversation option "I'm here about the trouble at the Salty Mast." which allows you to progress the SaD quest (even if it isn't shown in the Journal). After this you can progress the quest as normal: go and talk to Maea and you should be able to ask her about the prices, ask Bricanta to lower her prices, return to Maea and complete the quest. (For the record I tested all values between -2 and +12, as well as the value 20, in case it was a typo bug, for the IsQuestOnNode condition - all returned false, so I had to go with this event trigger instead.) (For the interested, event id 5 is "Found Aefre".) EDIT: According to my limited testing with this modification all is well... Aefre doesn't spawn until you've picked up the quest, so you can't talk to her before then. /check The conversation option isn't available if you talk to her before you've dealt with the thugs outside the Mast. /check Once you've agreed to help her, the conversation option isn't available anymore. /check You can't have any conversation with her anymore once the quest is completed. /check So as far as I can tell this fix doesn't break anything. However the real bug is that the quest disappeared from the Journal in the first place, this is just a workaround so one can progress normally regardless.
  4. This was supposedly fixed in 3.01, but seems it's back (or I've found another variant of it)... anyhow... I noticed, a looooong time after picking up the quest Supply and Demand (50h), that the quest was no longer present in my Journal. Not in progress. Not completed. Not failed. Just not there... (I read the name of every quest, twice, just to make sure I wasn't blind or something) I've killed the thugs out on the street. Talking to Aefre at the shack gives no conversation option regarding Supply and Demand, just "Who are you" and "Farewell" Talking to Maea still gives the "any news on those thugs" dialog. Talking to Bricanta gives no option related to SaD either (I've completed her task). Testing around I found that attacking Aefre unprovoked, killing her, and then talking to Maea again, enables me to complete the quest - which btw. magically reappears into the Journal, shown as completed, if I do so. It's really bugging me since I don't really want to kill Aefre, and I loose out on a lot of reputation being forced to do it this way, but since I want the 50% discount... Throwing away 50h of game time - that's how far back I have to go to still have the quest in my journal - isn't really an option. Here is my savegame: https://drive.google.com/file/d/1h7WbN1uq-Q92lSKPzB7Vm0sYsDt5PKw-/view?usp=sharing In this save, I'm standing in front of Maea, Aefre is still alive, and SaD is missing from the Journal. You can verify my statements: Maea still asking about the thugs, Aefre missing SaD conversation options, etc. Since killing Aefre and then talking to Maea magically makes the quest reappear in the Journal this is clearly a bug.
  5. I think you are just looking at the wrong page: https://pillarsofeternity.gamepedia.com/Maces (Also the wiki is maintained mostly by fans, so there is no reason to report it to Obsidian. It's better to ask in a more general section of the forum.)
  6. I was actually editing the wiki today to clarify this: https://pillarsofeternity.gamepedia.com/At_All_Costs Short answer: you need to confront him before you kill him. The conversation with Verzano contains a lot of triggers / two "cinematics" (locked interface while characters are moving). It introduces Pallegina's connection to this whole mess, and Danna will also arrive at the warehouse during the conversation.
  7. Oh, I forgot to include the output log. Well there is a NRE in StatusEffect.ClearEffect() I guess that's where the cookie crumbles - or in the caller? A debug-build should yield some answers hopefully. output_log.txt
  8. Quick disclaimer: I've verified files (steam) restarted client, loaded and reloaded saves - it's consistent and reproducible. Issue description: When I open Igrun's shop-screen (in the Copperlane market) the enchanted Plate armor in Eder's inventory looses all its enchantments. Steps to reproduce: Talk to Igrun. Ask to look at his wares. Details: I placed the Plate armor in his inventory so it's easier to see: one can see that it instantly looses it's enchantments as soon as the shop window opens - no further action required. The issue is the same regardless of whether or not the armor is in his inventory or he is wearing it - it seems to be tied to that specific item. Hovering over the armor in the shop screen, its sales price accurately reflects the enchantments it should have (500cp) - but moving the armor into the transaction area causes the price to drop to its unenchanted equivalent (200cp). Looking in the stash, at the armor tab, there is a wierd unenchanted ringmail that costs 500cp - but again, moving it to the transaction area causes the price to drop to its normal value. Sorting the stash on Sales price (e.g. Highest to lowest) and moving items into the transaction area, causes the remaining items to jump around randomly. If you open Igrun's shop, then immediately close it without touching anything, then save, then load the save, then open his shop again, the armor has its enchantments back - and the issue seems to be solved. However I'm worried it is not, and that my save contains some corruption that will rear its ugly head at some later point - perhaps irrevocably. Such is my fear. GoogleDrive url to save file (2.67MB): https://drive.google.com/file/d/1ThOP1LKAdfoEi-_0LMsPcce_afHDJcDO/view?usp=sharing Setup: Win7 (with all SP / updates) i5-4690K 16GB ram GTX 970 4GB (if u really need details I can include the dxdiag stuff on request, but I was lazy since this shouldn't be a system issue, but rather mismanaged item-ids or some other game-code or unity issue.)
  9. I know this thread is veeery old, just wanted to add that on my Swedish keyboard, รถ opens the console.
  10. It was 2.4GB for me - not that it's an issue for me personally (100/100) just wanted to add more statistics. It did feel like something was different when I patched to 3.7 a while back, but wasn't sure what. (It did feel like you could zoom further, but never confirmed it so might be my imagination.) Well it does look like a change in shaders / texture filtering - or they simply changed the quality level corresponding to each 'notch' on the quality sliders in settings, i.e. maybe 'normal' now is equivalent to the old 'low', 'high' is equivalent to the old 'normal' etc. (or any other custom change to 'default' levels of quality). It would be much more interesting if you could, include fps numbers increase the quality settings in 3.7 in an attempt to match the look in 3.06 (again with fps numbers) ...if you're up for it I would be very interested in hearing what you find. (fps-meter can be enabled in steam settings if you run on steam) Assuming I can increase the quality to match the old look if I so prefer, then I think it's perfectly ok if the drop in default-quality also gives a proportionate increase in default-performance.
  11. It is kind of funny how I asked this and modded my game only for the deadfire dlc to come out less than 24h later. Anyhow, seems like Alakabon is working on updating IE Mod, so that will hopefully come out soon. He did a quick test saying most things still seem to work: https://www.reddit.com/r/projecteternity/comments/7dc6ry/ie_mod_and_the_new_dlc/ Hopefully nothing changes in IE Mods API so I can try out your mod as soon as possible. (I understand that it probably works as is, but I'll wait for official support.)
  12. Am I imagining it or did you slightly adjust shaders and how far in you can zoom? (Maybe I'm just imagining it.)
  13. I'm sorry if this has already been answered before... does it affect save-games in any way? I.e. can I take a non modded save and start using this mod (and vice versa)? Or do I need to create a new character?
  14. For playing in 1440p resolution a font scale of 110% seems to have (so far) eliminated it for me. Excellent advice MaxQuest! As for why this happens in the first place... I have a partial guess. Basically I think it's a botched update-order of UI-elements / UI-scripts. Undesired UI behavior, i.e. vibrations, could emerge from the subtle interactions of these points: 1. Each UI text-bubble consists of a couple of grouped UI elements. 2. The position of these elements depends on the size of other elements in the group, basically automatic layout / vertically stacking them. 3. There is some special adjustment going on, causing something akin to coordinate rounding, probably trying to align text to screen pixels? 4. When the layout of elements depend on the layout of other elements, the (element layout) update order becomes vital! To understand why point 4) is so important let me explain to you why and how it can cause UI layout to flicker with a simple but representative example: Imagine having three UI elements stacked vertically. Lets simply call them Top, Middle and Bottom to make it easy to follow. One of these elements is our anchor, by which I mean that its coordinates are determined by something external to our example (e.g. by the position of your mouse pointer). In the case of PoE, bottom-up seems to be the way floating UI elements are "anchored" most of the time - regardless it is what I will go with for this example. As for the other two elements, i.e. Middle and Top, their coordinates are relative such that the Middle depends on Bottom, and Top depends on Middle. Basically lets call the vertical coordinate y, and assume the top of the screen is y = 0 in which case the above description can be eloquently expressed by these simple equations: Bottom.y = [some input value] - Bottom.height Middle.y = Bottom.y - Middle.height Top.y = Middle.y - Top.height So far so good. What could go wrong, right? Well the above coordinates need not be integers, they can be floats, and now imagine that for text rendering we have some pixel-alignment script, that rounds positions in such a way as to give nicely rendered text (to avoid text blur). Such a script would cause a small change in the elements y-value, which might seem innocent enough until you realize it can cause a cascading effect with a delay of one update cycle. (The update cycle might or might not be coupled to frames - it's not important but perhaps easier to understand if it is, so for simplicity we can assume it is a 1 frame delay. Don't worry if this sounds confusing I'm going to explain it properly below.) Specifically if the script and UI-element update order isn't properly determined, then we can randomly get "bad ordering" for some parts of the UI and not others. So what is a "bad ordering", and how does it actually manifest as flicker? We'll see this in the most clear way by putting in actual numbers into the simple equations above, and then follow the flow of execution for a "bad ordering" case through the rendering of two consecutive frames: 1. Lets assume the mentioned text-to-pixel alignment is applied to all three of our UI elements; Bottom, Middle, and Top. 2. Pick some random value for [some input value], lets say 800.0 for this example (any value will do). 3. Pick some "bad ordering" of UI script execution so we can showcase the issue. For this example lets go with the following order: [Calculate all height values] --> [Calculate all y values] --> [Perform all text-to-pixel alignment] Looks deceptively innocent right? Well anyway I also have to specify the relative order in which our UI elements update. This is also part of the order and we can't look at the execution flow without determining it. Lets assume the following order for our (unfortunate) example: Top --> Middle --> Bottom Still looking deceptively safe and sound? Wrong! 4. Render the first frame: a) Calculate all height values - Lets say our UI elements have the following heights: Top.height = 124.8 Middle.height = 50.4 Bottom.height = 98.2 b) Calculate all y values*: Top.y = 526.6 (651.4 - 124.8 ) Middle.y = 651.4 (701.8 - 50.4) Bottom.y = 701.8 (800.0 - 98.2) c) Perform pixel alignment (basically some rounding scheme, lets go with round-to-nearest): Top.y = 527 (+0.4) Middle.y = 651 (-0.4) Bottom.y = 702 (+0.2) d) Draw our UI elements (at the above coordinates). *Lets assume that asking for an y-value that has not been previously calculated / cached triggers its calculation, so for the very first frame we actually have Bottom->Middle->Top order. Lets refer to this as the "cache assumption". (We are doing simple layout on a flat surface so any sane UI configuration should be free of circular dependencies.) 5. Render the second frame: a) Calculate height values - These have not changed so refer to 4.a above. b) Calculate all y values: Top.y = 526.2 (651.0 - 124.8 ) Middle.y = 651.6 (702.0 - 50.4) Bottom.y = 701.8 (800.0 - 98.2) c) Perform pixel alignment: Top.y = 526 (-0.2) Middle.y = 652 (+0.4) Bottom.y = 702 (+0.2) d) Draw our UI elements (at the above coordinates). ...Oops! Notice that the coordinates for Top and Middle are no longer the same - they have changed by one pixel! Now there are multiple caveats with this particular example... 1. If you continue to render frame 3, 4, 5, etc. you will discover that our UI elements continue to climb higher and higher on the screen. Obviously this is not the case in practice so this particular example is extremely horrible - i.e. the actual code used in PoE is much better than this, but as an introduction to the importance of execution order and how it can cause small instabilities this example is simple and sufficient enough. 2. Pixel alignment has been over-simplified. In practice for a multi-row piece of text, each line needs to be aligned separately, which might affect the height. 3. The actual gui has a smarter design, but I believe the flaw is of the same nature to the one presented here - i.e. something somewhere in the code is reading a stale value from the previous frame, causing elements to move slightly from one frame to the next. Edit: Gave it some further thought.... A more probable implementation is that the y-values of each element is independent of the y-values of the other elements - instead depending on a sum of heights, e.g: Top.y = [some input value] - Top.height - Middle.height - Bottom.height. The y-values are (seemingly) decoupled from each other thanks to this, affording much more stability. And (seemingly) pixel alignment wont affect this. ... Until you realize point 2 above about how multi-row text-to-pixel alignment might affect height very slightly. Because unlike my first example above, which is completely unstable and derails at the smallest error, this approach would be much more stable. But a small difference in height of one element, can push another element by a very small amount, even less than a single pixel, and that could still affect how the different rows of that second element gets aligned, which in turn can slightly change the height of the second element, and so and and so forth. Why this is a resonable hypothesis of what's actually going on is because in this case the "drift" of the elements is bounded by the size of the adjustment that pixel alignment can make and the number of elements involved - it can never drift infinitely like my first example, but it can make small oscillations! Edit2: By the way, the reason why fiddling with v-sync might seem to help some people is very simple: The oscillations happen over the frames rendered (fps), which is not the same as frames drawn to the screen. So if your fps is about twice* the refresh-rate of your monitor, then you will only see every other frame, effectively preventing you from seeing the oscillation. It is still technically occurring but never visibly displayed on your monitor. (*or any other multiple of 2)
  15. Weirdly you can actually loot Nyrid even if you take him prisoner. Just come back into the house a day or so later after completing the related quest and the loot will be there on the floor where he used to stand... It's not immediately there after sending him to prison - you have to wait and come back later... (for some weird reason that is beyond me...)
×
×
  • Create New...