DimkaTsv

Sorry... I couldn't stop myself. No offence. Octavia main considered Nezha skills boring? Main of frame which is so OP that people don't play for how boring gameplay for it is most of the time? Man, people do percept things very differently sometimes.

I guess it just transfers statuses, then instantly expires as CC cannot be applied, and explodes all transferred DoTs in one instance? (Isn't it 1.5x of total DoT damage or something?) Also... Wait... Really? Nezha augment is able to transfer EXISTING statuses? I thought it was only for statuses you inflict AFTER you impale enemies. Not before and after. Aka based on what said, you just prime enemies, then use S4 and every enemy shares their statuses with every other speared enemy in area? WTF? Now i DEFINITELY know why it was nerfed, if it worked like this. Because radius scaling becomes actually quadratic with number of mobs affected and potentially can cause status amount issues (which is why status spread bond on robotics were nerfed to have cap of statuses). It is potentially even more broken than Melee Influence, even if it could not tripledip in faction damage.

Good argument. I was not good enough to calculate part of circle, and that approximation could've also given skewed results. Sure. Point was that relative difference in area measured in ratio or percentage will highly depend on environment and placement. It won't ever go above raw area/volume percentage though. And tendency is that with larger radius you lose more useful area/volume simply because mobs cannot spawn out of bounds, in air or under ground. And with radius increase often enough larger and larger percentage of total area/volume becomes useless.

Actual effective area change is more often than not is way less than 75 or 90% (in case of 50m vs 23.85m circle and sphere). Due to fact that at least parts of effective area will be out of bounds for enemies, and more radius you get, more area is getting out of bounds compared to actually useful area. It will depend on tileset and your specific location as you said. But in common case AOE reduction is about 40-60% (aka up to 75%). For example this is circle area vs effective area on tileset. For example, if you have 50.35m radius vs 23.85m radius, 50.35^2*п=7964.32 23.85^2*п=1787.01 1787.0/7964.32=0.224*100=22.4% But (sorry, not geometry expert, so i will approximate areas here to rectangles instead of cropped circle fragment) but you are fighting in corridor 20 meters wide your loss is NOT 75%. 50.35*2 (it is radius, duh)*20=2014 23.85*2*20=954 954/2014=0.4737*100=47.37% Meaning that practical loss would be 52.63% instead of 77.6% which could be though from base area calculation. And if you do AOE volume difference will be even more drastic. 23.85^3*п=42598 50.35^3*п=400800 42598/400800 =0.1063*100=10.63% with raw volume of sphere But, again, in reality actually useful volume difference will be like 40-65% approximately. While taking in account out of bounds via useful area based on same corridor of 20m width and 15m height, difference will look like this: 23.85m radius = approx (23.85*2)*20*15=14310 (as it fits in XXlength*20width*15height in meters virtual hall completely) 50.35m radius = approx (50*2)*20*15=30210 14310/30210=0.4737*100=47.37%. Aka 52.63% loss instead of 89.37% you could see with raw volume diff. Actually now that i noted, both of these differences came down to 52.63% loss. For both area and volume calculation. ------------- But don't get me wrong. I also agree that 50% nerf was too much. 25-30% would've been better option. I am just pointing out that raw area calculations are quite deceptive in terms of real percentage difference.

Simeris will also lock you from using S4 after using such order: S2 S3 S4 S3 S2 S4 On other hand i understand why. ESO is intented to lock you out of abilities. And Dante isn't only frame who relies on spamming them. Nobody will change ESO for single frame.

[SPOILER: REDACTED] Or wait... Now that i am triple thinking, you may have intended to convey slightly different situation. Basically any modded damage (or combination of it) will be placed into absract slot (0) for elemental damage (not mods, just abstracted elemental type slot). Then goes innate and imbuement with order based on it's type [Heat(1) - Cold(2) - Electricity(3) - Toxin(4)]. And i just mixed them up in one pile... So by this logic Electricity innate + Toxin modded + Heat imbued ==> does not interpret as Heat(1) / Electricity(3) / Toxin(4), but as Toxin(0) / Heat(1) / Electricity(3) instead. Yeah... Now that makes much more sense. What an annoying and obscure rule. (especially as heat is first to get cucked). Seems like i really need source of small amount of corrosion damage on my Nepheri. And by no chance i can get just small amount of it, without consequences on status weighting... Well, today i learned. When i do remember a lot of stuff about Warframe obscure BS, but this one caught me off guard, as i never actually played with imbuements, so never looked into rules. Thanks. Now... Is must i do something to close topic? Or should is just drown with time? Tbh, probably some person will later stumble on it though googling.

Problem is such: Let's say that i have weapon with innate basic elemental damage. I use single basic elemental mod with this weapon. And i use single basic element imbuement with augment. In process of figuring out rules i parsed every combination (except ones with cold innate weapons as currently don't have such at hand), and in general it is pretty consistent that imbuement prioritizes combination with modded elemental damage, freeing base weapon element as additional proc. Aka Toxin base + Electricity mod + Heat imbuement ==> Heat forced + Radiation high chance + Toxin low chance (due to weighting shift). Or Electricity base + Toxin mod + Heat imbuement ==> Heat forced + Gas high chance + Electricity low chance. But there are two major inconsistencies. 1. Heat innate damage completely ignores these rules, as it always combines first. Moreover. It will also ALWAYS combine with modded elemental damage as priority, and not imbued element. For example (incorrect interactions): As you can see all of these combinations produced radiation, instead of corrosion and magnet respectively. Reason for this is that innate heat prioritized merging with modded element over imbuement. These four samples are all following expected behavior, but only because heat is not innate element of the weapon. 2. Cold base and Electricity modded will merge into Magnet damage, unless heat is involved, then heat forcefully prioritize merging with modded elemental damage. But at the same time when heat is involved it takes complete priority: Main thing is that i want to know if such elemental merging priority rules are bug, or intended behavior. For example priorities for heat damage merging seems to be way off mark. I have excel table of combination tests. And only noticeably broken things, based on what i saw are ones that i mention here. But if someone wants to help me with innate cold weaponry, i would accept your input. ----------------- Main reason why i asked this question, is that based on what i managed to scrup i should have ability to make this combination: heat base + toxin modded + electricity imbue = electricity forced + corrosion + heat remnant. But i freaking cannot because heat ignores merging rules! So i get [gas + electricity] instead... And that's it!

Problem is not that they combine. I account for that when i build. Problem is rules by which they combine. It is inconsistent that i can make force radiation + heat and still keep toxin base weapon, because imbuement only mixed up with electricity mod. But i cannot do same with heat based weapon. Aka toxin base + heat mod + electricity imbue = electricity forced + radiation + toxin (with decreased proc rate due to weighting) toxin base + electricity mod + heat imbue = heat forced + radiation + toxin remnant (aka it still merged with mod and not base) But heat base + toxin mod + electricity imbue = electricity forced + radiation and not [electricity forced + corrosion combined with mod + heat remnant from base]. Meaning suddenly, because it is heat, now imbuement merges with base element and not mod. and heat base + electricity mod + toxic imbue = toxin forced + radiation. Meaning that it also always prioritize radiation instead of merging with imbuement (spoiler no matter what you will imbue here, with heat base and electricity mod you will always get radiation + imbuement separately). That is HUGE difference in behaviours between different combination of imbuement, modded elemental damage and base element of weapon. And i am questioning, did DE intentionally programmed that heat will ALWAYS combine ignoring default behavior no matter the source, or is it a bug. If it is bug, i want it to be fixed. And if it is intended behavior, then please make imbuement freaking consistent with rules! It should not prioritize specific combined elements over others. From what i saw specific combinations take priorities. 1) Heat will ALWAYS combine, no matter where it is. If heat is in base elemental damage of the weapon, it will prioritize combining with modded elemental damage and not imbuement for some ungodly reason... 2) If there is Electricity as innate element and Cold modded, they will combine into magnet (which should not happen, cold should combine with imbued element and free innate electricity). Unless there is heat, then it will be blast (or radiation) as heat will take priority and will merge by rules (with modded elemental damage taking priority) I wanna have ability to make this combination: heat base + toxin modded + electricity imbue = electricity forced + corrosion combined with mod + heat remnant. But i freaking cannot because heat ignores merging rules! So i get gas + electricity... And that's it! Resolved: There is specific rule for that Order is always such: 0) Modded element 1) Heat innate or imbued 2) Cold innate or imbued 3) Electricity innate or imbued 4) Toxin innate or imbued. When you have multiple elements in "innate or imbued" it will work just like mods but with fixed spacing 0-1-2-3-4, meaning modded damage will always merge with leftmost "innate or imbued" element, and right most will be added on top.

Well... With how fast squad (not you alone mind you) can kill mobs, it basically becomes infinite duration. Which is kinda op if i may say so... They only capped max duration you can stack so timer won't become like 10 minutes. Basically all timer increasing abilities have such limitations already.

Depends on combination. I would also enjoy if someone with weapon that has base cold damage but not-guaranteed one gives me some info on how elemental combinatons would work. Sadly augment behavior is inconsistent depending on combination, to be specifically it seems like Heat merging overrides everything, aka DE intentionally (or unintentionally) made it in such way so you could not split heat damage from merging. Electricity is forcefully merging in some combinations as well. In table below you can see, that you are physically unable to merge imbuement with elemental mods instead of weapon base element, if that weapon is base heat: I still would like if someone will make test of cold base weapons, as i don't currently have one. It will help me to provide priority list. Currently it seems like priority is like this: 1) Heat + Electricity, no matter where 2) Heat + Cold, no matter where 3) Electricity + Cold, no matter where 4) Heat + Toxin if toxin is a mod and not base Maybe i am wrong though. Merge means that imbuement combines with base+mod creating new element Add means that imbuement adds damage on existing combination Mod means that imbuement merges with mod, and you can still get such combination of element in order of frequency (Forced imbuement + [mod+imbuement combination] + base weapon element) Separate means that imbuement does not merge, instead weapon element will still be base+mod, and imbuement is completely independent.

Hm... Let's go into DM's for now, so we won't litter all over unrelated topic.

When it crashes just go to latest lines. There will be error specified. It is not necessarily that you will always see what you expect though. Atm DE have debugging through DRED Breadcrumb mode enabled, so it will give slightly more information than usual. For example one of my crashes due to too low voltage when undervolting GPU. [Again, this one is my own fault. Do not look too deep, it has no relationship to topic itself]. 0x887A0005 (or DXGI_ERROR_DEVICE_HUNG) error is most frequent one when you do OC or UV.

Not sure, actually. There are a lot of possibilities. But EE.log right at moment of crash may have cleared up picture a bit. Maybe stock OC is wonky for you, and Warframe is very sensitive to unstable OC's (hence why i use it for testing). Maybe you ran at some combination of location/settings that is broken for DX11, but i never do that content, for example.

Can confirm that. I also tried that exact combination (and one with armor strip) to see that Vulphaphyla doesn't use her basic attacks at all. Only mods. This actually also brings a point of locking down my companion lifelink recovery to 4 seconds cooldown of viral quill.

Now that is weird. I played DX11 when DX12 was disabled. Except ones that happened due to my own "negligence" (aka i am in progress of testing of OC parameters), i had no reproducible crashes on both 6750XT and 7800XT. Meaning that if you had issues with DX11 there were most likely NOT related to card being from AMD. AMD related issue was specifically "Reproducible frequent crashing on DX12, when Enchanced Shaders parameter is enabled. Can happen more frequently in new tileset"

Thank you, Megan. I was one who did big part of the testing to localize issue to specific parameter in settings. Re-enabled DX12 at moment of patch. Had not encountered issues which happened at WitW release since that patch. Well, except part that on DX12 shader caching is quite annoying and causes very noticeable stuttering when it happens for first time on every shader. I know that DX11 has less performance, but at least it processes most shaders on first load (basically every new zone, frame, action, enemy, effect, etc.). Is there something that can be done to reduce shader caching stutters frequency for DX12? For example precache them similar to how DX11 processes them. (Well maybe another one is graphical bug. Certain red flags at Steel Fortress on Earth are not actually rendering atm. I know they should be there, and sound is still here, but since some update i cannot see them).

DE intentionally disabled DX12 for AMD cards back then as one parameter for DX12 caused regular, reproducible crashes. They re-enabled ability to launch DX12 for AMD cards that Tuesday as they patched down issue and released fix.

Interesting, because i somehow managed to clear 2 mirror defences in a row right now. one on 2 waves and second on 1 wave. Usually it was about 80% crash within first wave fiesta. Which will probably mean that amount of runs for my tests was lacking. I am so tired already, though. Too many runs in a row. It also may be interaction with environment shade quality - medium / volumetric fog quality - medium and high quality shade - on. Because now for test purposes i have them set to high, while my default was medium. But if anything, i don't disable settings i enabled through previous attempts, so they have significantly smaller chance to be unstable ones as number of runs increased multplicatively for each attempt ------------ UPD: LOL, just edited that previous paragraph in during mission and i finally got my crash on third run. Issue localized to one of these 3 settings - confirmed. Yeah, high quality shaders caused issue from time to time in MANY games. So seems reasonable to assume it is probably this parameter specifically. Because glow and shine should be quite simple parameters. Last crash report: WAR-3865471 I guess i will stop here. Should be enough information. And i will go to sleep)

Oh, ok then. Just unexpected, as most people have issues with DX12... Only ones who said that they had crashes on DX11 and switching to DX12 helped them are owners of RX 7000 GPU's, besides you, so i assumed other reasons as potential cause. Yes, stock values should be fine, in theory at least. But way it crashes for you already doesn't show HW or driver instability. ---------------- UPD: DX12 all graphics settings to minimum. Ran 1 Alchemy and 3 mirror defence missions without crashes. Looks fine (except, well... graphics. Lighting to be specifically.) Attempt 2: Will try now setting everything BASE graphics contain to max. Otherwise it would take FOREVER to filter stuff one by one. (Only issue will appear if it is conflicting parameters and not singular one that causes crashes.). Aka: Geometric quality - high, Shadow quality - high, Texture quality - high, Particle quality - high, GPU particle quality - monstruous, TAA 8x + sharpen 20% with increased sharpness of temporary visual effects set on, Anisotropic filtering - 8x, Trilinear filtering - on. Everything from advanced graphical settings will be turned off for now. --------------------------- My system: Motherboard - Gigabyte X570S Aorus Elite AX CPU - AMD Ryzen 7 5800X3D 8-Core Processor GPU - AMD RX 6750XT AORUS ELITE running at PCI-E 4.0x16 RAM - Kingston Fury Renegade 3600 16-20-20 (OC to 3800 16-21-19 - TESTED) PSU - Deepcool PQ850M Primary drive - NVME, Game drive - NVME, both running at PCI-E 3.0x4 ----------------- ----------------- UPD: Ran 3 mirror defence (2 1 1 rounds) - fine. But there is absolutely horrible lighting Floor can go from too bright to too dark for location within few degrees camera angle inside same room. Attempt 3 - This time high normal settings, dynamic lighting - on, volumetric lighting- on, local reflections - on, shading quality - high, volumetric fog quality - high. Everything else still will be disabled. 3 more mirror defences to go. Still hadn't gotten Corvex part) ----------------- UPD: Ran 3 more mirror defences, no crashes. Need to look further. Oh, hey, i finally got Corvex part from mission!. Attempt 4 - Turning elemental effects - on, color correction - on, contact shadows - on, character shadows - on, solar shadows - on, improved stickers - on. Only disabled settings for now are [high quality shade - off, motion blur - off, depth of field - off, distortions - off, shine - off, grain - off, glow - off] Now lighting looks correct. Seems something tied to shadows. ---------------- UPD: Ran 3 more mirror defences, no crashes (1-1-2 waves). Looks like issue is in last batch of settings? Shaders? shine? glow? Attempt 5 - Turning high quality shade - on, shine - on, glow - on (intensity - 25). Other parameters still off. Entry door of mirror defence on new tileset (one directly in front after loading from hub) have flickering light for some reason - consistent.

Strange. DX11 should not crash from my experience (at least not on RDNA2). Are you sure you don't have too low voltage at medium frequencies (around 2300-2400 mHz usually), or your OC is not too high? Also, there are two ways game can crash. - First way, game freezes and quits with error to send to DE staff. If game crashes like that - that's what people currently look into - Second way, EVERYTHING freezes then goes black screen and GPU resets with driver crash report. This one should not happen frequently, and mostly will be tied to OC/UV or game itself / AMD driver (with less probability). But with such crash you have higher chance to potentially see reason in EE.log file I will try to run DX12 with different settings now. Lighting is potential issue? Because in some tiles of new tileset on DX11 light is flickering while you are in bullet jump. Attempt 1. Reduce everything to minimum.

Load is not an issue. Transients are. And Nvidia RTX 3000 series are known for terrible power consumption spikes. Even if your GPU is rated for 230W, power spikes can reach 500-550W. JUST for GPU!. It happens for very short time, and such spike won't EVER be reported to system, especially as all Nvidia power management is average based. But PSU's are definitely feeling it, and if power spike overwhelms capacitance - system will shut down. Not sure about RX 500 series though. But RX 6000 is not that much better than RTX 3000 in that matter (even though yet still better) And all "constant max power load stress test" like Furmark + Prime95 - yes, it gives a lot of power load... But it is consistently high power load. So your transients won't ever show up. Moreover some PSU models are much more susceptible to power transients than others. For some reason even running days Warframe doesn't shut down system for me, meaning there is something for you on hardware level. Because GAME SIMPLY DON'T HAVE ACCESS TO ABILITY TO SHUT DOWN YOUR PC. At least normal games don't and Warframe definitely wasn't hacked by someone who injected trojan to shut systems down (and if it was like that, issue would've been much more widespread)

Warframe is surprisingly optimized game that can load system harder than most games will do. It also can detect instabilities when others can't do. Granted it isn't perfect and can crash without hardware issues (which happens for me occasionally on SP Circuit for some reason. But it isn't driver crash, just game errors with DXGI_DEVICE_HUNG) And knowing that such thing as transient load power spike exists i would advice you to look onto power related issues. Any game related issue would've either crashed game or driver. But if there is nothing going on with your system game cannot simply cause shutdown event. Just to emphasize my point. Google for Nvidia "new world incident". Load caused system to shut down but bad GPU (RTX 3080 or 3090) power management overlayed on top and fried quite a number of people's cards. GPU AIB's and Nvidia are even rolled out new VBIOS versions with stricter limits to fight that. Trying framerate cap is good point to start testing.