Not All AA Displayed
 

I'm attempting to create a PoP-era server. I've managed to get most of the core functionality working, so now I'm working on tailoring the content to be correct. I logged in to a test character and noticed that Luclin-era AAs are visible and available, but PoP-era AAs are not visible. This occurs in both the Titanium and SoF client.

Here's an example of an AA that should be displayed, but is not. This is the Ferocity AA (melee archetype AA):

aa_abilities table:
altadv_vars table:
I checked rule_values for anything specific to AA and didn't really find anything other than xp per AA, max slots, and "stacking". Are there any specific settings I should look for or further information that would be helpful? Please let me know.

Edit: Oops. This was intended for general support, not Windows support. I was digging around for the answer and must have forgotten to swap forums.
Edit2: Side note while talking about AA. Is the "BotAAExpansion" rule a reference to the raw expansion number (8=OoW) or bitmask (8=PoP)?

Bump?

My World:ExpansionSettings value is 15 on all rulesets.

I'm still scratching my head on this one.

Edit: This happens on the Titanium, SoF, and UF clients with a max level character.

I can say for certain this setting is a bitmask. I've read a few threads where people say it can act kinda funny but, that could be dated info.

All enabled up to:
* I read you wrong - couldn't get over needing 4 screens to fit the thread in =p

maybe this will help more http://wiki.eqemulator.org/p?Server_Rules&frm=Main

Expansion Value:
Hot 10,118
CtoF 60,182
TDS 90,780

We revamped the AA system to be more inline with how live is. This means that the pop ranks were merged into other ranks. I'm guessing you see for example Innate Strength having 15 ranks instead of 5?

sorry to ask this in an unrelated thread, but if we are talking about world:expansionsettings and say we wanted to allow up to TDS

There's 3 different values listed in just this one thread...how do we decide which is right
1048576
2097151
90,780

?

The 1048576 is the bitmask value in ExpansionSettings for -just- the TDS expansion.

The 2097151 is the bitmask value for all expansions up to and including the TDS expansion.

Not sure what the values Noport linked are for.

Shaendare
I don't use numbers pulled out the air for World and Client Expansion
Expansion Value: you can use what you posted if you want too
Hot 10,118
CtoF 60,182 Recivied from client produced a string error 6,082
TDS 90,780

I'm still lost there. You're clearly talking about something other than World:ExpansionSettings in the rule_values table.

I have no doubt that it has something to do with the expansions, though, Opcode Ninja.

Shaendare
I don't use numbers pulled out the air for World and Client Expansion
CtoF Client produced a string error code 6,082 was change after fixed 60,182
Expansion Value TDS: you can use what you posted if you want too
player_tables
rule_values
variables
(5,'World:ExpansionSettings','90780','Expansion settings. Affects client features related to expansions.')
('Expansions','90780','Accessible expansions for each player','2010-09-06 15:03:51')

Interesting, so either one will work? Maybe this has something to do with the "funny" thing about this setting people noticed some time ago, unless they were mistaken. I use the bitmask and it works so far and that's as much as I remember about it. It was a post from at least a couple/few years ago.

Only one way to find out.

The innates in General are 5 ranks in my current setup.

Side note, if a mod wanted to chop up the text within code tags in the OP, that's fine with me to stop the left-to-right scrolling. I guess we have a time limit on being able to edit our own posts.

Ohhhh, so these are values the client expects to receive from the server regarding which expansions are enabled, and they don't follow the bitmask pattern we use in the server code with 1 bit per expansion.

I think ima have to experiment a bit!

I had UseClientBasedExpansionSettings disabled in ruletypes.h prior to compiling. I've since disabled it properly via an entry in the rule_values table (or should it be in the variables table instead?). I assume the setting was working when altered in ruletypes.h, since the AAs are being limited to SoL instead of the expansions of the client. I just figured I should do it properly so something doesn't screw up on a future git pull.

I've been digging around the code and I can't quite nail down where the expansion limit comes into play. I'll try upping the expansion limit a bit and see what happens when.

Well, setting the ExpansionSettings variable to 31 (LoY and all prior) made PoP AA appear. Just to see what would happen, I set it to 16 (LoY only). It showed only PoP AA. I'm even more confused now.

Edit: 24 gave me SoL and PoP AA. It's almost like the bitmask values are being doubled.
Edit2: Well, not doubled, but shifted. 1=Vanilla, 2=Kunark, 4=Velious, etc. If that's correct, then 24 was SoL/PoP and 23 should be Vanilla/Kunark/Velious/PoP (so no SoL AA should show). I'm trying that now... and 23 shows only PoP AA. I have no idea where this shift would have come from.
Edit3: The only changes I had made to source was a hack for old-time race xp penalties in zone/exp.cpp, some default rules changes in common/ruletypes.h, and a hack to try to limit client types on the server (still not sure about this one). To be safe, I've hard reset back to HEAD and am recompiling. We'll see what happens on the new binaries in a few.
Edit4: Recompiled. Same result. Thoughts?
Edit5: Yes, I like edits, apparently. So AA is acting as if the expansion bitmask is shifted, but other things tied to ExpansionSettings aren't (such as Frogloks being allowed when set to 31). This is really confusing.

I might have just found the issue (though I'm SUPER rusty with C++ and terrible with bitmasks in general). In zone/aa.cpp, on line 1421, there is the following code:

If I'm reading this right, it's checking the expansion value (forced by World:ExpansionSettings in the rule_values table) against the expansion for the AA. If we use the example that I'd originally quoted, Ferocity, that expansion value is 4. So the bitwise left would be "1 << 4", which is 1*4^2 or 16. That would evaluate "0" after the bitwise & against an expansions variable of 15. As such, shouldn't the code be:

This would be 1 << (4-1) or 1*3^2, which is 9, which would evaluate "9" after the bitwise & against an expansions value of 15.

I made this change and recompiled zone. The AA's showed up properly (SoL and PoP together) when using an ExpansionSettings value of 15. I changed it to 8, restarted the server, and only PoP AA showed up, as expected.

Could a dev take a look and see if I'm correct here or let me know if I'm a complete idiot?

After today's update to eqemu_update.pl, I tried updating my AA tables via the script and recompiling zone without the above modification. They again showed an expansion behind. I was hoping maybe my AA table having the old data was the problem, but apparently not.

Any thoughts on the above code modification being right or completely wrong?

Guess there aren't a lot of people working on expansion limiting AAs after the revamp to chime in. :/

I'm definitely interested and would help if I could.

you might have to bush up on your c++ programing and work with eq_packet_structs

There's no brushing up possible. It's strictly learning from the ground up. =P

So I took a look at this again today and I think I was right above, but for the wrong reason.

I looked into bit shifting a bit more and realized I was calculating it wrong above (though still coming up with kinda the right answer). I think my logic needs to look at what possibilities should evaluate true. I'm going to do a bit of rambling just to get thoughts down into the thread. Feel free to pick any of it apart.

Earlier, AdrianD posted the expansion value chart:
If we convert that to the bitmask values, we get (inclusively, it would be all bits after the initial 1 also being 1 instead of 0, but that wouldn't really change anything):
Now, if we look at bitshifted values of expansions from the AA table (results after the "1 << rank->expansion" calculation), we have:
So in the code now, isn't it comparing SoL (0100, or inclusively 0111) to the bitshifted AA expansion variable for SoL (1000)? If so, then wouldn't this always evaluate false, making the code correction posted earlier correct?
Again, I'd kind of like a dev (or anyone who knows this code, C++, bitmasks, bitshifting, etc better than I do) to take a peek and let me know if I'm insane or not.

I haven't been ignoring this one..my online time is limited and I've attempted twice to respond to it - without luck...


You can set bitmasks up to represent just about anything..but, looking specifically at the expansion value chart posted (re-posted) above:

Kunark has a bit value of 1 and a bitmask of 1.


A standard ordinal bitmask will usually exclude 0 from its rankings due to the fact that the lowest provable ranking value is 1 - there is no 0's column
in bit representation.

To convert an ordinal bit ranking to bit position, yes, a simple (1 << (ord_val - 1)) should be used. For cases of 0, you would simple prove it by
checking (bool)ord_val == false or ord_val == 0.

SIDENOTE: You can create a positive mask for validating greater than the ordinal ranking by using (~0 << ord_val). C++ doesn't implement bit rotations,
so there is no chance of a wrap-around with a standard bit shift.


In the case of Kunark, converting the 'value' to a bit position in the coded example does indeed produce 0x02 where the mask is 0x01.

However, look at what is being considered: CanUseAlternateAdvancementRank

Since the transformation reflects a greater than positional value, and there is a 'false' return methodology, you really don't want that condition
to be true for an exclusionary check.


There's a lot of systems that I'm not up-to-speed with - this being one of them.

But, looking at what is defined and what is being checked, I think that particular code snippet is correct. That's not to say that there may not be
issues elsewhere (these guys are pretty sharp and usually catch logic errors pretty quick.)

Kunark would be the oddity. I hadn't considered it, since Kunark didn't have any AA availability.

Perhaps I'm misunderstanding your intended message, but since it returns false on a not true, the result from the bitwise & should be true if the AA is to be visible to the player. Using SoL as an example, since I can break the comparison down to just a nibble, we currently have the bitwise & of the expansion bitmask (0100) and the shifted rank->expansion value (1000):
Throwing a not on that then evaluates true and in turn returns false, even though we obviously want SoL AA to be used if SoL is the enabled expansion

Which snippet do you believe is correct? The one I posted or the one in source. Perhaps the above bit in this reply is wholly unnecessary.

[Still think I'm missing something here...]


Let me ask around on this one..it's very possible that we need to adjust some things.

From my limited testing and logically, it should work. I'm not intimately knowledgeable of the source, though, so I wasn't sure if anything else needed modified accordingly.

Thanks for taking a look!