I know that originally the bag limit for professions was 3 and then Chaos changed it to 4, but I was simply wondering if it has increased since then. Otherwise, I need to toss my Cole Bag or Master Mineral Bag so I can make use of another 8-slot bag I found from Monster Park.
Couldn't find any posts on this since late 2011, so I'm sorry if this question is going to get someone to shout at me. :<
Why does Nexon keep limiting the helpful things like this...I dont like throwing away quest items just to get another 4 slots from a bag. We should be able to use 10 bags of we want.
Why does Nexon keep limiting the helpful things like this...I dont like throwing away quest items just to get another 4 slots from a bag. We should be able to use 10 bags of we want.
But, but, but, it might cut down on your slot expansion purchases!
I wish they'd remove the hard cap on inventory size. And char slots, while they're at it.
We should be able to expand as much as we want, as long as we pay for it, of course.
I wish they'd remove the hard cap on inventory size. And char slots, while they're at it.
We should be able to expand as much as we want, as long as we pay for it, of course.
The issue with inventory size is the view all button and their UI. I do think they should raise the character slot limit though. I hear that they do in Tempest but only to 18. I don't really see what the issue is considering most of the new classes don't share CS inventory and the only main "cash" benefit for having more chars on the same account is just storage space.
The issue with inventory size is the view all button and their UI. I do think they should raise the character slot limit though. I hear that they do in Tempest but only to 18. I don't really see what the issue is considering most of the new classes don't share CS inventory and the only main "cash" benefit for having more chars on the same account is just storage space.
Actually, the issue in both cases is the structure of their database. A technical issue that's about as likely to get changed as the irrational client-server relationship.
semi-technical explanation
The database they use is composed of tables.
In this sort of database, there are two basic ways of dealing with items that can have multiple instances of related items.
For example, let's consider a vehicle license database for the DMV: They need to know about people and cars, and the relationship between them (i.e., which person owns which car(s)).
One way to do it is to have one table. Each row is for a person, and contains columns for Name and Address and such identifying information, and then information about Car1, Car2, Car3, .... How many "Car" columns do we put in this table? How many vehicles can one person own? Well, there's no legal or physical limit (other than the number of cars in existence, I suppose). But since this is a table, if we allocate 1000 columns to cars, every single row will have those cells, even if they're empty. Lots of wasted storage space. The advantage, however, is that when they pull up the row for Mr. StellarAshes, the information about all his cars is right there. No need to go looking for it elsewhere on the hdd.
The other way to do it is to have two tables. One with information about people, and one with information about vehicles. The people table contains no information about vehicles at all. The vehicles table has one row per vehicle, and that row has the ID of the car's owner. If they want to see all the cars owned by Mr. StellarAshes, they have to ask the database to fetch them all from the vehicles table. This entails some search work by the database program, and likely several reads from the hdd as it goes and finds the various bits of data wherever they were stored (at different times probably). It's a much slower process than the one-table solution. However, it does not limit the number of cars per person, and it does not waste space on empty cells.
Nexon chose to do it the first way. It helps the game run faster, but at the cost of wasted space and consequently a fairly low hard limit on "expansions" (because the space for a full inventory is pre-allocated for each and every character, even if they can't access it until they pay).
At least, this is the way I think they did it. It's the only reasonable explanation as to why they won't accept our money to expand further. No doubt someone better informed will correct me if I'm wrong.
Actually, the issue in both cases is the structure of their database. A technical issue that's about as likely to get changed as the irrational client-server relationship.
semi-technical explanation
The database they use is composed of tables.
In this sort of database, there are two basic ways of dealing with items that can have multiple instances of related items.
For example, let's consider a vehicle license database for the DMV: They need to know about people and cars, and the relationship between them (i.e., which person owns which car(s)).
One way to do it is to have one table. Each row is for a person, and contains columns for Name and Address and such identifying information, and then information about Car1, Car2, Car3, .... How many "Car" columns do we put in this table? How many vehicles can one person own? Well, there's no legal or physical limit (other than the number of cars in existence, I suppose). But since this is a table, if we allocate 1000 columns to cars, every single row will have those cells, even if they're empty. Lots of wasted storage space. The advantage, however, is that when they pull up the row for Mr. StellarAshes, the information about all his cars is right there. No need to go looking for it elsewhere on the hdd.
The other way to do it is to have two tables. One with information about people, and one with information about vehicles. The people table contains no information about vehicles at all. The vehicles table has one row per vehicle, and that row has the ID of the car's owner. If they want to see all the cars owned by Mr. StellarAshes, they have to ask the database to fetch them all from the vehicles table. This entails some search work by the database program, and likely several reads from the hdd as it goes and finds the various bits of data wherever they were stored (at different times probably). It's a much slower process than the one-table solution. However, it does not limit the number of cars per person, and it does not waste space on empty cells.
Nexon chose to do it the first way. It helps the game run faster, but at the cost of wasted space and consequently a fairly low hard limit on "expansions" (because the space for a full inventory is pre-allocated for each and every character, even if they can't access it until they pay).
At least, this is the way I think they did it. It's the only reasonable explanation as to why they won't accept our money to expand further. No doubt someone better informed will correct me if I'm wrong.
I run a Maple database website as well as having rather extensive knowledge of PS, and having briefly went over the assembly/MsSQL databases of BMS, so believe me when I say that I do know my way around DBs. The issue I was talking about with the character slots is the incentive (or lack thereof) for Nexon to allow people to purchase additional slots.
As for the technical explanation you give, I know for sure PS uses the second method. I don't recall off the top of my head what BMS used. Also, the "speed" improvement of the first way over the second way is so miniscule (less than 1/100th of a second if indexed/keyed properly) that it's hard for me to believe Nexon (well, technically, Wizet) would do that. Then again these are the same coders who accepted item IDs from client as if they were always correct so I could be very wrong.
I run a Maple database website as well as having rather extensive knowledge of PS, and having briefly went over the assembly/MsSQL databases of BMS, so believe me when I say that I do know my way around DBs. The issue I was talking about with the character slots is the incentive (or lack thereof) for Nexon to allow people to purchase additional slots.
As for the technical explanation you give, I know for sure PS uses the second method. I don't recall off the top of my head what BMS used. Also, the "speed" improvement of the first way over the second way is so miniscule (less than 1/100th of a second if indexed/keyed properly) that it's hard for me to believe Nexon (well, technically, Wizet) would do that. Then again these are the same coders who accepted item IDs from client as if they were always correct so I could be very wrong.
I think @Eos; once said that the BMS database used no indexing, but I could be misremembering.
As for the incentive for more character slots: since the one-account-per-person restriction was removed from the ToS, we all have infinite storage. Except for untradeable and account-locked items. Nexon should actually encourage us to purchase new slots on existing accounts, rather than create new accounts with free slots on them. The fact that they don't indicates to me that they have a technical issue blocking them, namely a non-dynamic database structure.
I think @Eos; once said that the BMS database used no indexing, but I could be misremembering.
There are some random indexes here and there, but not many and not where they'd be most useful.
For the tabs they'd be fine to add slots indefinitely, well, up to 2,147,483,647, clearly more than anyone needs, they use an ordinal value positioning system with a separate table per tab. Note the incrementing POS column that defines the ordinal location.
ETC Tab Sample;
Spoiler
SN
CharacterID
POS
ItemID
Number
ExpireDate
Title
Attribute
ItemSN
1
2
1
4000295
1
2079-01-01
0
0
2
2
2
4000185
1
2079-01-01
0
0
3
2
3
4000057
2
2079-01-01
0
0
4
2
4
4000129
2
2079-01-01
0
0
5
2
5
4031189
1
2079-01-01
0
0
6
2
6
4031170
3
2079-01-01
0
0
7
2
7
4000176
2
2079-01-01
0
0
8
2
8
4000128
1
2079-01-01
0
0
9
2
9
4031175
2
2079-01-01
0
0
10
2
10
4021008
1
2079-01-01
0
0
11
2
11
4000027
1
2079-01-01
0
0
12
2
12
4031222
2
2079-01-01
0
0
13
10
1
4006001
100
2079-01-01
0
0
14
10
2
4000004
17
2079-01-01
0
0
15
10
3
4000000
18
2079-01-01
0
0
16
10
4
4000010
2
2079-01-01
0
0
17
10
5
4010001
1
2079-01-01
0
0
18
10
6
4000001
12
2079-01-01
0
0
19
10
7
4000016
14
2079-01-01
0
0
20
10
8
4000003
5
2079-01-01
0
0
21
10
9
4000012
21
2079-01-01
0
0
22
10
10
4000011
3
2079-01-01
0
0
23
12
1
4000038
1
2079-01-01
0
0
24
8
1
4031475
2
2079-01-01
0
0
25
8
2
4031466
1
2079-01-01
0
0
26
2
13
4000014
2
2079-01-01
0
0
27
2
14
4001077
1
2079-01-01
0
0
28
2
15
4000285
1
2079-01-01
0
0
29
2
16
4000143
1
2079-01-01
0
0
30
2
17
4000049
1
2079-01-01
0
0
31
2
18
4000282
1
2079-01-01
0
0
32
2
19
4031195
1
2079-01-01
0
0
33
2
20
4000173
1
2079-01-01
0
0
There are no indexes on that, though there really should be a clustered index, or even primary key, on CharacterID, POS to immediately grab a specific spot in any character's inventory on demand. One would hope GMS or KMS would've done that by now, but BMS hadn't.
If I recall they use negative POS in the equip table to indicate which ones are being worn and where, so that table covers both items in your equip tab and items you're actually wearing.
I think @Eos; once said that the BMS database used no indexing, but I could be misremembering.
As for the incentive for more character slots: since the one-account-per-person restriction was removed from the ToS, we all have infinite storage. Except for untradeable and account-locked items. Nexon should actually encourage us to purchase new slots on existing accounts, rather than create new accounts with free slots on them. The fact that they don't indicates to me that they have a technical issue blocking them, namely a non-dynamic database structure.
Which is what I was stating before (that it's strange Nexon is limiting the # of chars per account). I don't think there is a technical limitation to the number of characters (and also as Eos has confirmed).
And I also stated that the issue with item slot expansion is that they have things like this set up:
I'm not saying they can't increase the inventory slot expansion because of this, but it would require them to do more work. However, there is little to no (technical) limitation on the number of characters per account, nor is there more work for them to do, therefore I said in my original post that they should definitely increase it.
The expanded inventory (view) option wasn't always in the game. They could have had unlimited inventory expansions sold back when you always had to scroll. I don't know why they didn't, just as I don't know why they won't allow unlimited chars per account (and even more, why they expanded in KMS to only 18 now. It doesn't even fit the UI. Should have been 24.)
Eos' confirmation that there is no technical issue leaves me completely puzzled as to their motives.
I wish they'd remove the hard cap on inventory size. And char slots, while they're at it.
We should be able to expand as much as we want, as long as we pay for it, of course.
But that would make logical business sense! People paying for things they actually want, and not random chances as getting items they almost do?
Bookmarks