Unique maps losing their Awakening Objective completion is unintended and will be fixed before 3.11.0.

FYI you don't need to use a legacy Vaal Temple to re-complete everything; any legacy T16 will do.

P.S. using the Map Stash to migrate your old maps to the current generation of maps means (by definition) they are no longer legacy maps and therefore will not complete your Atlas.

StupidFatHobbit

Thanks.

While I have your attention any chance you could answer this question about cluster jewels? I sent the following message to several devs and never got any reply (not really surprised at that either, it's rather technical and I figure probably only 1-2 people at the office know).

Hi, been trying to figure out what determines the order that notables appear on large clusters with 3 notables and 2 jewel sockets, specifically trying to find out which notable gets placed in the furthest spot (the one between the 2 jewel sockets).

Based on testing, I have so far determined that it is:

• Not alphabetical

• Not prefix/suffix related

• Not related to the internal mod ID #

• Not related to the cluster weighting value

• Not random (multiple jewels with exact same notables have exact same layout)

• Not related to the order they appear on the item itself

Can you shed any light on this? It actually affects high-level min-maxing quite a bit.

Thanks

It's arbitrary but deterministic. No simple way to know just by looking, sorry.

GGG still hasn't implemented as "HasInfluence None" command

Good idea. I'll make it happen.

Thanks for your awesome filter btw!

This is not intended and will be fixed.

Shtevenen

They're ignoring this... In the other thread /u/RhysGGG said "It's not been changed. It's 10%" and blew off the hundreds of people saying the same as you (and me).

Seems like they're not looking into it.

That was not my intention. I just meant we didn't intentionally change anything. We are looking into it.

zeerimunin

If it is indeed two separate rolls (first 10% for master and then roll which master) they how I am at such a high spawn rate?

Yes I have 118 maps with masters out of 297. Even taking into account the ~17 Jun's and ~15 Zana's I forced that puts me much higher then 10% chance.

It is two separate rolls. First it rolls a 10% chance to spawn a master, then it rolls to see which master to spawn.

You must be using a bunch of master sextants, scarabs, prophecies, and/or atlas missions to get that many. Or you're exceptionally lucky?

Piros1987

They purposely nerfed it, because master mission chance is an Awakened Map completion bonus now... but the nerf was just supposed to be a drop from 8% (5=40%) per master to 7% (5=35%), with full awakening bonus boosting it to 9% per master (5=45%)

Sounds like they messed something up with the change...

I haven't had any problems, personally... I've encountered a couple of each master in my 50-75 map clears... hard to say if it's lower than it should be...

Natural master mission chances were unchanged in 3.10.0 (still 10% for a random master, of which there are 5 possibilities, equally weighted). Edit:I mean we didn't change anything intentionally. We are looking to see if there is a bug.

We only changed the Atlas Mission chance, from a flat 40% chance to a scaling chance (35% at awakening level 0, up to 45% at awakening level 8). Which appears to be working just fine. Edit: the chance scales from 35% to 45% based on Awakening objectives completed, not Awakening Level.

I'm not sure why the natural masters wouldn't spawn. The only things that are supposed to prevent them spawning in Maps are other sources of Masters (master sextants/prophecies/scarabs/Atlas Missions/etc), plus a few obvious special cases like Blighted Maps and Unique Maps.

nasaboy007

Thanks! Could you also get clarification if the increase is meant to be only within the region, or is it global? Like if we 3x favorite a map in New Vastir and nowhere else, will the game say:

1. "you have maps in many regions unlocked for this tier, and so your favorite map is 30x more likely"

or

1. "Your map is 30x more likely ONLY if you were to get a map of that tier in New Vastir, and a mapdrop from a different region doesn't care about favorites"

The first is correct: It's global.

just_a_fart

Doesn't this only apply to the first 4 watchstones?

You are correct. You seem to be having a different issue.

For now, you can try searching other regions for watchstones, or try using 4 watchstones (even though it says you only need 3). We will keep investigating.

You may need to explore the corner regions first. More info here

Xeverous

For sockets specifically, base types that could never have sockets were matching false against all socket filters, even things like Sockets <= 6

That's exactly how comparison against null or NaN works - it's always false.

I have changed this in 3.10.0 so everything has 0 sockets, and will match as such.

How about other properties? Eg if I do Class "Divination Card" MapTier >= 1 will it catch cards or not? If not, then it (possibly accidentally) implements "comparison against null/nan" behavior. I'm just interested which conditions have such behavior.

I see what you mean. I just had another look through, and I think socket matching was the only case. Everything else should match as zero, not "null".

But please let me know if you find any other weird behaviour!

Dissolator

Can you please share images of new icons? so i don't have to wait for ggpk and datamine them to add into 3rd party tool... and rgb of colors for beams would be cool to get too! :)

p.s. Does new colors only work for beams, but not for minimap icons? previously it was possible to use same color for icons and beam effect on one item.

Torrent is up lol

And yes, the new colours work for both beams and minimap icons. The beams and icons should all have the same set of matching colours.

briansd9

Hi /u/RhysGGG, thank you for the clarifications, I have another question.

Resonator sockets are currently indicated by "DV" in the JSON returned from the item data API. Will this be changed to "D" to conform with the filter syntax?

Unlikely, for backwards compatibility reason

Xeverous

Isn't there a sort of distinction between matching against 0 and "null"?

For example, Class "Divination Card" will match any card. But If I add Sockets <= 6 it will stop matching any card because cards are not treated to have 0 sockets, they are treated to have "null" sockets and any comparison requiring any socket number always fails.

Is such behavior intended? Can you list what items have "null" instead of 0? /u/_xhul_ already mentioned some inconsistency for sockets with jewellery items that seems to exhibit such implementation.

We don't have any concept of "null" in the item filter. For sockets specifically, base types that could never have sockets were matching false against all socket filters, even things like Sockets <= 6. I have changed this in 3.10.0 so everything has 0 sockets, and will match as such.

Quelex

Which post? They don't appear on the following posts:

• Patch Notes
• Gem Info
• Item Filter + Skill Tree info

They appear here for me

_xhul_

I was partly wrong, the bug isn't actually specific to "0" arguments, more like specific to non-weapon and non-armour classes in their intirety. For example, "Sockets < 6" and "SocketGroup < 6" fail to match an Iron Ring aswell.

While i'm here, could we get some details about that "Added new item filter drop effect colour options." 3.10 patch note?

Yeah, there were a few problems with matching against zero.

We are adding new drop effect colours, matching minimap icon colours, and new minimap icon shapes. The info should be posted up sometime today.

_xhul_

Thanks a lot for those precisions.

I retested another bug i mentioned previously, and since you didn't reply, just in case you missed it: The 3.9.2f recoding of "Sockets" & "SocketGroup" has a flaw, specifically when used with a "0" argument. A few examples to illustrate: "Sockets 0" and "SocketGroup 0" will never match an Iron Ring, despite it has no sockets. Similarly, "Sockets 0" and "SocketGroup 0" will always match an Unset Ring, despite it actually has 1 socket. It's worth noting that that behaviour seems to be restricted to non-weapon & non-armour classes only ("Sockets 0" and "SocketGroup 0" will successfully match Kaom's Roots, for example).

Glad to hear you'll take a look at the interaction between "Class" & "==", that will actually grant us more flexibility in the order in which we declare our blocks, cool.

About legacy prophecies, i was surprised they got that treatment, compared to the many player-drop-only bases that can still be referred to, i guess because the "Prophecy" condition was implemented after those got removed from the pool of seekable ones.

I will fix the "Sockets 0" bug. Thanks!

connorjohn322

did they say anything about white map strat?

We fixed that too

Xeverous

Thanks, do you mind checking 2 more things? /u/_xhul_ mentioned few really weird things in https://github.com/xhul-github/xhul-filter/blob/master/misc.txt - I'm mostly concerned about legacy prophecies that are not accepted and == being reported to not perform an exact string-string match for Class as it is the case for BaseType.

The item class not using == is definitely a bug. I will try to fix for 3.10.0.

Quest items must be filtered with an explicit item class (Class "Quest Items"). This is intended, not a bug.

Disabled Prophecies cannot drop and cannot be filtered. Also intended.

Relational operators work with CorruptedMods. Yes, why wouldn't they? It's just a number, after all. It works the same as all numeric rules (ItemLevel, AreaLevel, etc).

Undocumented item classes and base types, including "...". Please do not rely on these. They are scrapped concepts, WIP data that hasn't yet been removed, or occasionally necessary for non-item purposes for various internal reasons. They may change or be removed, and we assume item filters do not need them. These items cannot drop anyway.

The font size is a bit strange, yes, because the limitations depend on the font itself, which is different depending on your language. I don't know if we can improve this easily.

Xeverous

Thanks, but didn't you mean (255 - 50)? 0 is fully transparent, 255 is fully opaque. Default black-but-a-bit-transparent background for common items looks more like 205 than 50.

Oops, that value is not correct. Was looking at the wrong code.

The default text colour and border colour is (ARGB) 255 200 200 200.

The default background colour is (ARGB) 240 0 0 0.