The Beast Within -- A Guide To Blue Mage

Definitely our best option for TP, just not by a huge amount.

I've let some of the sets get outdated as I took an extended break and only just came back to the game this last week. I'll get every set, even including Requiescat, updated by the end of the weekend.

once it's at rank12 i think it's safe to assume it's bis.

gets stp+4 at rank12, if you need attack combatant's (on spreadsheet) tends to win out just cause of att, so stp+4 matches that at least then crit and str should push it above.

crazy acc bonus anyways it probably starts winnging around rank 9ish

I agree with this,

It's possible to get 600 skill but all you can do for recast is the empy hands then fc ~10ish? (ammo ear ear and 1 ring?)

There was a discussion recently where someone was grossly underestimating how much fc you need to cap, give me a second and I'll quote add my test under this:


So at -capped magic haste- you still need empy hands and +23 fc to cap

In terms of Colada augments:

Does an ideal Colada to serve as an off-hand to Almace look different than an ideal Colada to serve as a mainhand weapon?

(Also, I assume Tanmogayi's delay and lack of augments make it a far worse off-hand weapon than it was a main hand weapon, yes?)

Does reforged Relic feet need to be equipped for diffusion JA or the spell used after diffusion?

They need to be equipped during spellcasting to gain the benefit

I would think the ideal looks the same. Only difference is you can afford to give up DMG+ on an offhand with little consequence.

You are correct in Tanmo

There are a ton of things in game that go by decimal this is completely wrong.

Using RA WS since they are so much nicer to test with...
Last Stand on a Wild Rabbit
Observed:
Base: 6,440
Earring On: 6,568

Expected:
6440 x 1.02 = 6,568
6440 x (1 + 5 / 256) = 6,565
6440 x (1 + 6 / 256) = 6,590

that eliminates 21 / 1024 and 22 / 1024 as well, so the only answer would be decimal.

I guess I was completely wrong

Where does Karieyh Ring (or +1) fit within these ring rankings?

So I often hear talk of Sequence/Almace vs Almace/Sequence from people with no conclusive evidence. Say if both were augmented (hence both losing major advantages they have in the main hand vs the offhand), any idea which combo comes out ahead?

tp bonus on crit ws these days isn't -that- amazing.

Almace/Seq >>>>>>>>>>>>>>>> seq/alm if cdc spam. (and this was before new augment boost)

the real arguement isn't alm/seq vs seq/alm it's alm/seq vs tiz/alm

I was looking at killer traits on bg-wiki.

On the individual testing, it shows Blue gets Tier 3 of the killer traits.
However, the reference links just point to the old Bst testing.

Does anyone know if Killer traits were ever tested for blu after the 100 jp and 1200 jp gifts?

The values were given by the Devs

Thank you!

People talked about sequence because before rema augment and wsd glitch savage blade was a thing. And sequence is made for savage.

For savage, vampirism is likely the better offhand unless I'm missing something. Almace doesn't seem like a good choice for an offhand when spamming savage blade.

hepatizon sapara +1 is an exceptional option, only really losing to an extremely good STR/WSD Colada. And it's cheap as all Hell.

vamp actually holds up really well if you're lacking attack at all according to the spreadsheet,

I also don't think sheet includes the extremely tiny boost from draining tp

but not
85899346/4294967296
32bit interger division

32bit interger divison with bit move should still be faster than a float division (to have enough precision to emulate "perfect" decimals)

If you had to be anal there is not.
All the math is binary it just a matter of precision enough to emulate decimals close enough.

You might ask in code to do X * 1.1 in decimals.
But the instruction will still end up in binary for the CPU to work it with its imprecision

Different brand of CPU's will even do the rounding differently
(or used to they might all be following the IEEE standard now)


my points is that all the x/256 amd x/1024 could be all the same on eveb bigger divisor (e.g. everything that goes x/256 could be x/1024 we just didn't evidence of precission before)
it could alle x/65535 (16 bits) division) we just haven't seen small enough steps to verify it

Been using Claid for offhand savage.

don't.

i really doubt someone went in and made such a long fraction when they could just do .02. just because a computer reads it that way doesn’t mean it’s coded that way

It very common pratice to use bitshit instead of division.
its such acommon practive to avoid divison that compiler will try to avoid it when converitng you source code to machine code
The hardware in your cpu tries to avoid it even when its raw assmebly codes tries to do division.
Hence the old well known fdiv bug in the first generation Pentum becuase the lookup table in the CPU had some faulty entries in it

its not more difficult coding wise to do 32 bit shift vs 8 bits shifts from a human skill level

So I would have to disagree on all levels on this statements

The entire reason we do /256 or /1024 or /~4bll
is because these a hole numbers in binare and therefor can easily be replaced with bit shifts which is MUCH less stressfull in cpu ressource



To clarify its not coded as x/256 or x/1024 as in multiply with X and then divide with 256 or 1024
Is coded as multiple with X and move these bits 8bits over or 10bits over or in my case 32bits over ( when A bit get move outside the range of the the storage units it is "Deleted" hence why as default any divison is truncated / floored.

The code different is minimal
and its a very common practice among coders. compilers and hardware to do so


Besides the 32bit bit shift was just an example not necessarily a proof that we needed 32bits to achiever the precision to get the results from testing.
We might need way less. i just started in the extreme spectrum to show that its possible in binary math and the negate that the test was any kind of proof of decimal math

The computer does EVERY calculations and the rounding in binary no matter how you type in code as a human.

P.S.
If im not mistaken ( and please correct me if you know)
but working with 32bit register in moderne cpu are faster than its 8 and 16bit counterparts. because of how the fetch and prediction units works in morderns cpu.

This was VERY apperanty in the Pentium PRO cpu as thier 16bits performance was horrible compared to its 32bit performance. but later on on the pentium2 som more shift on cpu isntruction to MicroOPS convertiob was improved ( E.G the cpu internally converted some 16bits math to 32bit math)

I would not be suprised if S.E. over the time changed the base divison going fomr 8bits hsift to 10bit shift to maybe 16 bit or 32bit shift.
all earlier data would still fit as before as you simply add more 0 to the X values. but never gear could archieved higher precision.

not saying there is any proof of it but its a possibility from both an accucacy and performance perspective

Lets just try for the fun of it

1317/65536 (16bits shift) would also make give the +128 test results
163/8192 (13 bit shift) would also make give the +128 test results
82/4096 (12 bit shifts) would also make give the +128 test results
41/2048 (11bit shifts) would also make give the +128 test results
21/1024 (10bit shifts) is to high
20/1024 (10bit shifts) is to low

So anything above 11bit shift gives the needed precision for binary math to come up with the 0.02 as show in testing.


In coding "You" always want to vaoid
- divison
- multiplication
- Working with fractions (Cause that implies a division and also intergersmath is way faster then fixed or float point math)

So even thoug it appears on the human side we do something with 0.02 very rarely do we actually do that when the math is actually done by the computer.

I 100% support your post, but I just want to say this was my favorite part:

I assume you understand that when you start adding in additional sources of WSD, that those shifts won't add up and the most logical way to calculate WSD is as a base 10, unlike haste and fTP anchor values which all hold up /1024.