Gob Sack

[Greatguardian]

Are we still certain that the inventory is being changed server-side in the first place? I hadn't picked up on that. If they had required a server-side query, then the act of changing multiple pieces of equipment quickly would be laggy and prone to mistakes. You would also be unable to change equipment if your internet connection was cut off at any point.

I'm fairly sure this is not the case. Equipment changes appear instantaneous, and the game can recognize 16-slot changes over the span of 0.1 seconds. You are also able to change your equipment on your client while R0'ing (though if you completely disconnect, the server is never notified of these changes and thus dismisses them when you log back in).

It would make more sense to me if equipment checks are done client side, and only the relevant final data is sent to the server where the actual stats/calculations are done. This would be the fastest, most efficient method, I'd think.

[Arcon]

I was fairly confident that it does take place server-side, but you've got me wondering. I didn't know you could even change gear while R0ing for example. Of course the server does perform the final check, if there's a client-side check involved, it would be to reduce server-spam, so that people don't try to equip items they can't wear all the time. Also, it would help the client change gear before the actual gear change takes place, if the change is valid, which makes it appear as reduced lag.

The amount of items changed doesn't matter so much, as the duration for sequencing the data that's being transferred is still minimal compared to the actual round-trip time (which is the major delimiting factor), and it does in fact cause lag sometimes, which skips certain gear changes. Although to be perfectly honest, I'm not sure if that's always due to this lag, or if there are other factors involved.

Guess I'll have to do some further testing when I get the chance to log in next time.

[Greatguardian]

Well, as for skipping gear changes, this seems to happen more as a function of macro stacking than server-side lag. For example, on the PC version of the game using single lines to denote 16 gear swaps, you can change your gear and use a stat-dependent JA (Chakra) at the same time and get the exact same expected result every time.

eg:
/console exec ChakraGear.txt
/ja "Chakra" <me>

The real gear jumbles start appearing when you have to hit multiple macros. I've been given the impression that each line in a macro is taken sequentially with minor innate delay, rather than simultaneously. This tends to account for the majority of macro-mishaps that occur when two macros are pressed back to back, as pressing a new macro will automatically break/discontinue the previous one.

There is definitely a final check server-side, though, as when you R0 you can change your equipment but your model won't actually blink out. It's my impression that actual item stats are stored server-side, so while the client may be able to tell the server what items you're wearing and what action you're taking, the client won't know what any of those items do until the server processes that information.

Eg: Rather than sending a packet to the server saying "Hey, change my gear to x/x/x/x/x/x/x", and then sending a packet to the server saying "Oh hey, also make me use Chakra", I think it's more likely that the client sends a packet to the server saying "Hey, Greatguardian just used Chakra while wearing x/x/x/x/x/x" followed by "Hey, Greatguardian just attacked the monster while wearing y/y/y/y/y/y/y"

[Arcon]

There is definitely a final check server-side, though, as when you R0 you can change your equipment but your model won't actually blink out. It's my impression that actual item stats are stored server-side, so while the client may be able to tell the server what items you're wearing and what action you're taking, the client won't know what any of those items do until the server processes that information.

Eg: Rather than sending a packet to the server saying "Hey, change my gear to x/x/x/x/x/x/x", and then sending a packet to the server saying "Oh hey, also make me use Chakra", I think it's more likely that the client sends a packet to the server saying "Hey, Greatguardian just used Chakra while wearing x/x/x/x/x/x" followed by "Hey, Greatguardian just attacked the monster while wearing y/y/y/y/y/y/y"

The way I would have implemented it (and the way I'm implementing it), is that the client only transmits actions, not the current status of the character (since the server has the priority information anyway). That would save on lots of information having to be sent. It wouldn't take much longer to send that information, but it would create a much higher network load, especially for the server. Gear-information isn't that massive, but if everyone would send it virtually permanently, it would accumulate to quite a lot.

Wouldn't your system imply that the server could "revert" changes, if they don't coincide? I don't remember ever "seeing" that taking place, although it wouldn't have to be a visible (or noticeable) process.

How exactly do you mean that gear changes work during R0? I thought you meant the model blinking, but if that's not it, what else? Or you mean that it won't give you an error during a job change?

[Greatguardian]

The way I would have implemented it (and the way I'm implementing it), is that the client only transmits actions, not the current status of the character (since the server has the priority information anyway). That would save on lots of information having to be sent. It wouldn't take much longer to send that information, but it would create a much higher network load, especially for the server. Gear-information isn't that massive, but if everyone would send it virtually permanently, it would accumulate to quite a lot.

Wouldn't your system imply that the server could "revert" changes, if they don't coincide? I don't remember ever "seeing" that taking place, although it wouldn't have to be a visible (or noticeable) process.

How exactly do you mean that gear changes work during R0? I thought you meant the model blinking, but if that's not it, what else? Or you mean that it won't give you an error during a job change?

As far as reverting changes, do you mean if action packets are received out of order? I don't think it would necessitate changing your gear for you, though the actual effects of said gear may not be processed properly. The calculations for ability usage and attacks are all done server side, so the only important information that the client has to send the server consists of what you're doing, what you're wearing and/or what your stats are.

In order to prevent client-side stat "injection", personally I would have designed the system in such a way that the stats themselves are only determined on the server's side, while the gear the player is wearing can be determined client side (for speed, mainly). It is far less dangerous to allow the client the potential to trick the server into thinking they're wearing a Judge's Greatsword than to allow them the potential to trick the server into thinking they are brew-mode gods 24/7.

As far as gear changes during R0, you can still "change" your gear and get Equipment Changed messages. Whenever your connection is restored, you will be wearing whatever you last told the client to put on you. However, the actual stats on the gear won't affect your character until you restore your connection. I'm actually not sure whether or not the model blinks now that I really think about it -_-. I've had a fairly stable connection for a while now. It very well might, and now I'm not really sure at all. Regardless, it doesn't actually do much of anything since the server doesn't know what it's supposed to be doing.

@Seriha, sending a 16-object array along with your actions to the server is hardly a bandwidth hog =/. Attacks don't just loop, they have to be processed by the server individually whenever the client actually attacks. When the client turns to face away from the target, or moves out of range of the target, it does not attack. It is not a simple while(Status == "Engaged") loop whose interior can be marginalized.

The difference between relying on the server to store your equipment information and update that information only after a request from the client, and the client telling the server items/stats to use for each action, is the difference between occasionally weaponskilling in the relative strength of your Chakra gear and vice versa depending on your connection speed and the speed of your actions. From a gameplay perspective, it is significantly more accurate for them to allow the client to tell the server what the player is wearing for each action before the server runs each calculation than to rely on the server to have up-to-date information on the player's gear status every time it runs a calculation for them.

[Draylo]

Drop ps2 support!!!!!!!!!!!!!!!!

[Feynman]

Greatguardian and Arcon, I /salute you!

For most people on here it seems that your conversation would have turned into a huge fight. Instead you guys talked, made good points, exchanged ideas and provided something useful to this forum.

I am not a programmer so I thought all of this was very interesting and was happy to be able to read it without tons of slander and hate laced through it.

[Seriha]

Eg: Rather than sending a packet to the server saying "Hey, change my gear to x/x/x/x/x/x/x", and then sending a packet to the server saying "Oh hey, also make me use Chakra", I think it's more likely that the client sends a packet to the server saying "Hey, Greatguardian just used Chakra while wearing x/x/x/x/x/x" followed by "Hey, Greatguardian just attacked the monster while wearing y/y/y/y/y/y/y"

Which would be a grossly inefficient method of coding its own right. For the sake of bandwidth, only individual changes should be registered as they happen. The fact multiple changes can happen simultaneously to our perception doesn't mean they are, it's just computers doing what they do (compute~) sequentially and at great speeds.

In the case of gear swaps, the most rudimentary method to do it would be a combination of If/Then statements. We know the enactor is the /equip command. As I posted earlier, the game has to know where to look for gear, and bluntly, SE would be a bunch of idiots if they let the client dictate what was actually in their personal inventory. Since the /equip command doesn't require the inventory/sack/satchel windows open to work, the whole "PS2 limitations" line is pretty pointless to invoke. Either way, the server knows what you have. The server must look where this knowledge is stored before commencing checks like job/level/race requirements. If you fail that check or the server doesn't find the requested item in your inventory, nothing happens. If the item is there and you can wear it, the next move would be to remove what you're currently wearing, sequentially subtracting any stats it offered. Once that is done, the new gear piece is equipped with all of its modifying values added onto your collective parameters.

So, instead of looking at a series of auto-attacks where "player auto-attacked in xyz gear", the last part was defined the moment anything happened to their data to determine the relevant stats (gear swaps, (de)buffs, JA use, etc.). Technically, we don't tell the server we're auto-attacking every time, either, as that's a process that begins when engaged and repeats relative to our delay. We're at the mercy of the server sending the info back saying that not only did we auto-attack, but for the client to run the animation(s) for your weapon(s) and view the result in your log/onscreen.

Multiply this with thousands of people online at a time and all that needless data of full equipment reports from the client for every single action would add up. And since we've probably all experienced congestion lag (Think the busy times of Beseiged and Campaign) once zones start breaking 100+ people, these checks are probably somehow related the zone server(s). Personally, I've had equip macros fail in these situations where they'd otherwise work. I've also found that trying to run a wait at anything under 0.7 seconds for multiple swaps in a single slot tends to result in a failure of the second one going through if the first wasn't on already. Some might argue this a client issue, and it may very well be a contributor, but I can still remember my newb days when there'd be over 200 people in the Dunes and I'm in a party near no others where swaps messed up and pulled mobs would 'teleport' from point to point until secured by the tank. So, there's a definite critical mass in server transmission somewhere, with the 720+ number being when things get really, really unstable.

Veering back to the /equip command, though. Variants to account for the sack or satchel technically aren't needed. Two more layers of checks could be added where after it checks your main inventory for the item, it sequentially goes from satchel to sack looking for it if it isn't in the prior. From a computational perspective, this could get resource heavy for every time it has to jump to the 2nd or 3rd array, maybe cutting that 720+ number down to 240+. As such, this is why 3 individual commands may be better since they'd still be individual checks up to 80 instead of the bing-bang-boom of 240 run sequentially for each 80 with an all-in-one.

Regardless, I still feel we should have a higher capacity for active use inventory through one of the two methods. I do not want to see "job sacks" since it'd be a nightmare juggling things that aren't All Jobs but more than one in what would translate to 21+ inventories. If SE did veer toward that route, breaking the distinction down to equipment slot would be more easily managed. I feel like we're a bit too late in the game's life for that, though.

[Seriha]

I still think you're sending pointless data with your proposed equipment method. As long as something isn't actively happening to change your stats, a performed action, either by or to you, can be pulled indefinitely from the stored data collectively harvested through base stats, (de)buffs, and gear. It's also more friendly to the tic system since the server doesn't have to ask the client if you're wearing something with regen/refresh/regain/etc. for each and every slot every 3 seconds because it should already know when those parameters were set involving the related stats. It also basically parrots monster stats since while they don't wear gear, side-by-side, they should look exactly like players when it comes to all possible parameters used to calculate combat data.

As for auto-attacking, it wouldn't be 'auto' if didn't loop. Haste/Slow aside, the act itself technically doesn't need to know our stats to run on its own, but rather they're queried to determine the result for when it can be successfully performed. The loop, in turn, ends if we die, the mob dies, or we disengage and is subsequently paused when the target is out of range/out of our frontal cone/we're slept/stunned or another action is performed like JA/WS/Magic/Item use. But as long as we're basically flagged for being in combat via /attack on, ctrl+a, or whatever, it will want to try and run forever. If that's not a loop, I don't know what is.

[Lokithor]

Gear is all managed server side to avoid client side hacks that would allow you to obtain any gear you like. Things that are not vetted server side are hackable (flee hack anyone?).