Random Question Thread (FFXI Related)

Why not? Its 6DW is pretty critical to us hitting the necessarry 9DW we want to cap our attack speed

Yotai+Eabani+Malig is another option but Gerdr + Dedition + Adhemar maths out ahead by a decent margin

However, I now sat down and run the numbers on various combos in the simulator

The key it seems is giving up Chirich for Defending ring, which shores up our DT, allowing us to have our cake and eat it too (use Gletis, Adhemar body, and adhemar gloves, and still hit 47 DT which is prolly sufficient)

At which point now the trade becomes

* OAT (Rostam Path B) + Chirich Ring
vs
* 6 TA and 85 WS Att (Gletis) + D Ring

and the latter definitely wins by a large margin for DPS, but you lose 2 DT (you go from 49 to 47)

However tbh 47 DT is prolly sufficient for most cases, and tbh probably the next thing to give up is an earring for if you want that last 3 DT that bad.

Not all -DT is the same.

Adhemar body with 50DT and Malignace or Nyame body also with 50DT.. there will be a massive difference in how much damage you take, how many debuffs land and so forth.

suppa/eabani is all you really need, or yotai + eabani, but the 2 earrings are the least invasive short of a standard DW+9 cape. You can go the route of adhemar body too, but i tend to keep it to 1 glassy piece a set and id personally weigh the gloves higher than the body as a swap.

If you are wearing Rostam off-hand, pretty sure the augments are not applicable - Main hand only, and if main-hand, then the argument is moot.

If you are sure that you have figured out a new meta with Rostam, why don't you just buy 2 of them and provide some empirical data rather than speculation and perfect-world simulations? Seems like you already have your mind made up with what you want, you are just looking for someone to validate your decision for you.

After reading about it, the alias method makes perfect sense if you want to do an extremely large sample of binomial probabilities in a given situation. I'm not really sold on the added complexity *or* it being more efficient in this case.

Swapping of equipment/buffs means that you're constantly remaking the distribution if you just make it per character, so at the very least you need to hash every combination of multihit any player on the server makes. That means either comparing for equipment changes or doing a hash lookup, just to save 2 calls to your random number generator. Doing a hash and corresponding lookup costs more than the extra random check if someone doesn't have all 3 forms of multihit (and the code likely existed when TA was only from THF traits and DA was sparse).

I also disagree on the 'used very often and needs to scale' component. It's a very small portion of the combat cost, 3x random number generation and if checks in native code once a second for maybe 100 players actively engaged per zone cluster.

Thanks for humoring me and explaining though, I understand your viewpoint better now and I learned a new technique. Just gonna have to disagree on it being a good fit here.

This. Taking away even one piece of high m.eva gear will cause a significant amount of moves to fail resist checks and double in damage. If DT is anywhere on your list of priorities, you probably shouldn't be considering anything that doesn't fall in the highest range of m.eva (nyame, sakpata, emp+2/3, malignance, af/relic+4).

Yes, I agree and I don't know enough about their requirements to say whether it's "better" or not.

It just depends how fast you want to be able to calculate MA. Definitely not worth the added complexity if it is in fact not time sensitive.

Typically it's used when:

* Probabilities are static
* Generating a number based on a set of probabilities will be used very often and is also time sensitive

If you're generating numbers every second.. again maybe, it depends how granular they are, how many engaged characters per zone and so forth. Idk enough to say.

If you assume probabilities are static, you're only looking at one character, so you can't assume it's being applied to every char gamewide because you have the added overhead of hashing/mapping/lookups.

But, they aren't even static to one character unless the person doesn't swap. Multihits are still evaluated on WS. If you use different sets for different WS, you can't even say one table per player for TP and one for WS since there'll probably be different amounts of multihit in your sets for each. Throw in a DT swap, it gets silly.

Think the real answer is that even if it can technically outperform, it's not by much and the cost is low to start with.

OTOH, I can see how it'd be blazing fast for generating random data samples of just about anything.

You don't have to generate once per change of gear.

You can generate it once for every possible set of probabilities.

QA will only ever be 0-X%, no more.

TA will only ever be from 0-Y%, no more.

and so forth.

Generate lookup tables for every set of probabilities and you have O(1) lookups for every possible MA gear option in the game. Grab a set of MA (qa, ta, da) for the character, get the lookup table you want for that set, and get your proc.

It just needs a bit of code to grab max MA available in the game as a whole and a batch process to generate the look up tables which you do once and update only when new gear is added.

Is it worth it? Idk, depends. I've done this for a realtime application and if you need it, it's great. A bit of work to do sure.

Looks like its about 120 Meva we lose, using adhemar gear over malig?

Trade off looks to be

Malig body/gloves + Suppa + Eabani + Sailfi:

HP: +68+57+45 = +170
Meva: +139+112+8 = +259
TA: +2 = +2
DA: +5 = +5
STP: +11+12 = +23
DW: 9/9

Adhemar body/gloves + Cessance + Dedition + Gedr+1

HP: +63+22= 85
MEva: +69+36 = +139
TA: +4+4 = +8
DA: +3 = +3
STP: +7+6+3+8 = +24
DW: 10/9 (slightly overcapped but doesnt seem to matter much for reducing tp/hit)

So the net diff of going from Malig -> Adhemar:

HP: -174
MEva: -120
TA: +6
DA: -2
STP: +1
DW: +1 overcapped (but prolly doesnt matter much)

So yeh, you lose a decent bit of max hit/ehp, but you gain a formidable amount of tp rate.

I'm curious about how much of a resist rate taking a 120 meva hit impacts survivability, I assume its a lot, since thats pretty much losing an entire armor slot's worth of MEva, so I can see the value in preferring that.

Your dps is zero if your dead, so I can respect that haha.

Chiming in here:

Looking up anything on the heap is almost universally going to be tremendously slower than just performing an ad hoc stack alloc'd calculation.

Lookup tables need the calculation to be very expensive before they become worth it.

CPUs are incredibly good at just doing the calculation asap.

When it comes to game dev, "just calculate it" almost always wins, because getting as close to 0 heap alloc is usually your goal.

And just moving to the next RNG value on your formula (prolly twister) is usually trivial.

There's a lot of interesting cases where the "on paper" LogN or NLogN speed algorithms actually end up slower than the N time algorithms, because you have to account for the fact that a real life CPU is optimized to do certain things way faster, and you have to account for stuff like heap vs stack lookups.

IE instead of doing hash lookups on a table or etc, just brute force for loops can often end up faster simply because CPUs are really really good at just iterating over an array super fast lol.

Yeah, no.

Iteration works for certain orders of magnitude.

In the millions, billion iterations and above, lookups are always cheaper idc what CPU you have.

Common misconception, just add a for loop and iterate.

Yeah, until you need 1B calculations before you do any work, then an in function for loop doesn't work anymore.

My experience is not game dev, but a realtime system is a realtime system.

The magic accuracy formula places 1 m.eva at either 0.5% hitrate or 1% hitrate depending on delta between you and the monster. In the best case scenario, you're fighting a [tunnel worm, eschan phuabo, omen trashmob, idk] and you're still capped and lose literally nothing. Or, you're fighting literally god and still floored and lose nothing(idt any mob actually exists where you can't get off m.eva floor with just gear any more, tbh).

But, you probably don't need DT in those situations. Worst case scenario is you go from the enemy having floored land rate to upwards of 50%. It's substantial enough that I won't ever consider anything without current gen m.eva in hybrid or DT sets, though it can still be nice in max damage sets for very weak content.

The issue is that you need to perform the lookup to reduce 2-3 random calls to 1, because you need to lookup every time the character attacks. The costs(1-2 extra random generations) you're talking about are so low that the very act of fetching the table wipes out the gains it provides. Obviously you can go steps further and save a pointer to the last lookup table used and see if it's hash matches. Maybe you even go a step further than that and allocate a giant chunk of memory for your lookup tables such that you can calculate the location in the chunk based on some non-floating point math using the DA/TA/QA values instead of true hashing, but it's still silly. You don't have exponential or even substantially iterative amounts of attacks going on to need that level of optimization.

No, genuinely doing the calculation each time probably will be faster, no matter how many times you do it.

Looking up on a table, which means having to access heap memory, will already be slower than the entire calculation as a whole.

Modern RNG algorithms are designed to be exceptionally fast to calculate on the stack for cpus.

So fast that the entire calculation will be faster than just doing a single heap lookup.

You have to remember that looking up on a table involves having to first calculate the hash of the key to lookup on, then traversing the keys.

I wouldn't be surprised if the RNG pull is faster than even simply just calculating the hash to lookup on, before you have even started actually looking up on the table.

So before you have even started to look at the table to try and pull the value, the RNG "in stack" calc has already completed.

It cannot be understated how much tremendously faster doing something on the stack with 0 heap involvement is.

Your general rule of thumb is this:

Your math is worth caching when the time to calculate it on the stack is slower than all of:

1. Hashing the input (Which is already a non trivial chunk of math here, many industry standard formulas are already faster than this step alone)
2. Traversing the lookup map
3. Loading the value in and copying it from Heap->Stack

And Im pretty sure most RNG algorithms are substantially faster than the above.

Fair enough, that is pretty substantial so I can see the value in that.

It obviously depends on the lookup calculation speed vs iteration.

I agree it doesn't sound worth it in this scenario. I can think of a dozen+ others where it is though.

Generally in realtime systems no one wonders what the cost of a memory address call on a heap vs a stack is, just how much absolute time it costs to do some work that you need to do one way vs another way.

If you can pre-generate a bunch of data to make that work go X times faster when you need it to, you do it. Within some reasonable limit of memory use, time cost to generate the data and so forth.

Offline calculation, pre-calculation, lookup tables and all that stuff are standard. And latency is measured in ns in these systems, not seconds.

Are you saying the roll for a TA/DA/single is done locally and then sent to the server or done on the server and sent to the client? As Dodik said, if you max melee speed on something like NIN how is it keeping up either way?

I can assure you, it matters and we very much care. A senior dev won't even "wonder" about it, they'll just roughly know "yeah there's nothing we are going to gain here by caching this stuff, I mean we can try and benchmark it but I'd be surprised if caching it is better" vs "This is a very expensive operation so we should cache it to improve performance"

And even the question of "do we greedy cache it" or "do we lazy cache it" too.


These are the same thing. Understanding is the key to good implementation. A good developer understands the "why" part of their implementation. They can tell you why A was better than B.

Blindly just throwing stuff at the wall without any idea of which is the right choice is not how you end up with a performant system...

Except for SQL, I'm pretty sure that's exactly how every DBA writes their SQL and you won't convince me otherwise. I don't think anyone truly understands how to deterministically write genuinely performant SQL on the first try, as opposed to "well what if we just flip these statements around, huh, its running 4x faster now, I have no idea why though"

If you try and tell me you can, I will just call you a dark warlock and assume you are operating under some kind of demonic pact or something.

all attacks are initiated by the server, the client just says where you are and who you engaged


max melee speed on nin is 320 delay (tsugumi+ban, not that anyone would use it) * 0.2 = 64 /60 delay/sec = 1.06667 seconds per round

there's nothing to 'keep up' with, one attack calculation for 2 hands is 6 random checks(DA+TA+QA), with less than 1/second frequency. even on asura, you probably max around 1200 players actively engaged at any given time

a mersenne twister RNG + a few value comparisons costs essentially nothing, the server could do many millions of them a second without batting an eye..every player could hop on nin and find whatever trusts have the most multihit and the lowest delay at once and you still wouldn't be registering an additional 0.1% cpu load from the multihit calcs [entirety of combat may be a different story]

Do I need abyssite of destiny to be able to farm Emperyan feet? or will it just make it quicker?

Discernment...? What is abyssite of destiny?

It's not needed, will only speed it up

Loads of FFXI models ended up in FFXIV. Can't FFXIV send over their models to FFXI in return (there are loads of options here)? Is there some kind of technical challenge to doing this?