Gob Sack

[Greatguardian]

As I said, I think you just misinterpreted the OP. What he said isn't limited by the PS2, because it doesn't affect the client at all. All it would have to do is send a chat line to the server, something the PS2 client is more than capable of doing.

Yes.

How do you know that? How do you know they ever made code like that? Do you think they check if the item is in your satchel, and if that's true, they won't let you equip it? Why would they do that, if there's no interface for us to equip from the satchel in the first place?

A good programmer would do this. Regardless of what the designer thinks the client SHOULD be doing, there's no telling how the client might decide to try to do things anyways. Why should a simple calculator block any input that isn't a number? Do people really try to add Z + leet * awesome? Well, yes. They could. And it would break their calculator. So even though adding words is retarded, the programmer has to allow for completely retarded/unanticipated input and make sure to restrict it from screwing up the program.

In an ideal program, you only allow exactly what you want to allow through, and block out everything else. If you only want your inventory to be equipable, you add catches to ensure that items in any other area cannot be used as equipment. I would be sincerely disappointed if SE's professional coders were so lax in designing fundamental code for use in a worldwide MMO.

Again, how do you know that? How do you know it's a ton, and not just one line, that would exist with or without satchels and sacks? Because that's how I would have done it. And if I could do it, SE can too. People need to stop insulting SE by repeating over and over again that their code could have been done better by a three year old disabled kid. Because if you're assuming what you do of their code, you're pretty much saying that.

I'm not even really sure what he (DefiledSickness) is even trying to say here. Though personally, even if I had implemented a block/catch with only one or two lines to prevent equipping items from non-Inventory areas, I would still have to do more than just delete that line. If I had a restriction in the first place, it was for security reasons (anti-exploit). Simply removing an anti-exploit measure and letting that be that would be an enormous breach of security. Even after removing the potential limitation to inventory-only equipment, they would have to redesign the code in such a way that players are able to equip from 2 sources but unable to find ways to trick the server into letting them equip from other sources.

It is just plain dumb as a coder to assume that either: A) No client is smarter/more savvy than you are, or B) No client will intentionally try to break/exploit/hijack your code. If the possibility exists, someone will pursue it. Taj made that abundantly clear when he still played.

This, on the other hand, would actually require a lot of changes to the code, the part of the code that allows only one item to switch places at a time. Ever notice that it takes twelve years, give or take, to swap out gear for different jobs from your Mog Safe? That's because the server prevents item transfer while another transfer is in progress. So if they gave us that option, gearing up from your satchel or sack would take ages, but it would work as it does now, or it would require them to change that particular piece of code (which would also be appreciated, but that, I believe, they won't ever touch, because it require looking at a lot of other things too, like trading and item drops from mobs, receiving rewards from NPCs, anything that involves the inventory in any way).

Ironically, this is also a simplistic security fix. There used to be no delay in moving items, and people exploited this in order to dupe items in their delivery boxes and other systems. They could remove the limitation, but that would require a significantly more sophisticated anti-cheating fix to the code which I highly doubt they'll pursue.

[Arcon]

A good programmer would do this. Regardless of what the designer thinks the client SHOULD be doing, there's no telling how the client might decide to try to do things anyways. Why should a simple calculator block any input that isn't a number? Do people really try to add Z + leet * awesome? Well, yes. They could. And it would break their calculator. So even though adding words is retarded, the programmer has to allow for completely retarded/unanticipated input and make sure to restrict it from screwing up the program.

In an ideal program, you only allow exactly what you want to allow through, and block out everything else. If you only want your inventory to be equipable, you add catches to ensure that items in any other area cannot be used as equipment. I would be sincerely disappointed if SE's professional coders were so lax in designing fundamental code for use in a worldwide MMO.

[..]

I'm not even really sure what he (DefiledSickness) is even trying to say here. Though personally, even if I had implemented a block/catch with only one or two lines to prevent equipping items from non-Inventory areas, I would still have to do more than just delete that line. If I had a restriction in the first place, it was for security reasons (anti-exploit). Simply removing an anti-exploit measure and letting that be that would be an enormous breach of security. Even after removing the potential limitation to inventory-only equipment, they would have to redesign the code in such a way that players are able to equip from 2 sources but unable to find ways to trick the server into letting them equip from other sources.

While in general that's all true, and security measures should be sure to catch all exceptions, in this particular system, what does it actually do? When I said interface, I meant a serverside interface. Right now, there's no possible way to send a query to the server to equip something from other places, because the server decides where it's equipped from. So having a catch for people trying to equip from their satchel is pointless, because there's no way for them to actually do it. So, no, the server doesn't have any code in place specifically restricting people from doing that. It has only code in place, that allows people to do certain things. And they simply don't have code to allow gearing from /satchel or /sack yet.

So they wouldn't have to worry about any restrictions, or violating some code that they have to revisit, they basically just have to copy the current code they have in place for the /equip command, and copy it for the /equipsatchel and /equipsack commands.

Although now thinking about it, it might not be quite as easy as this. They'd also have to make the equipped gear from /sack or /satchel show green, so they'd have to add a reference to where the gear is equipped from (and also restrict moving that gear around, although a mechanism for that is already in place, which they could also copy from the regular inventory). So maybe not quite as easy after all, at least not considering the surrounding features.

It is just plain dumb as a coder to assume that either: A) No client is smarter/more savvy than you are, or B) No client will intentionally try to break/exploit/hijack your code. If the possibility exists, someone will pursue it. Taj made that abundantly clear when he still played.

Very true, and SE is still behind on that part. See dead/invisible monsters still being transmitted to the client, as well as TP/MP of party/alliance members. All those things cry for abuse by any semi-talented coder. As I explained, I just don't think they allowed equips from everywhere, and then have a servercheck to make sure it equips from inventory only, but the other way around. So there would be no need for such restrictions in the first place, and invalid commands would never be executed at all.

Ironically, this is also a simplistic security fix. There used to be no delay in moving items, and people exploited this in order to dupe items in their delivery boxes and other systems. They could remove the limitation, but that would require a significantly more sophisticated anti-cheating fix to the code which I highly doubt they'll pursue.

I didn't know that, thanks for the info. And yes, unlikely they'd pursue such options, which kinda hints at lazy coding and half-assed fixes, but as long as it works, it's unlikely they'll touch it.

[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"

[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.

[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?

[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.

[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.