Architect Archive
Thread: PETITION FOR 200 ITEMS IN A MEDIUM HOUSE AND A CLIENT SIDE STORAGE SYSTEM FOR UNLIMITED ITEMS
Page 1 of 2
EboAda
Sat Mar 06, 2004 5:41 pm
#1
title says it all, obviously Medium houses cost more and take more resources to make, therefore should have at least 200 items if the large house takes 250.
also we should be able to save our items on our PCs so that we can store infinite amounts of items. we would have a set number of items that would be saved on the server incase we decide to play on another PC. these items would be considered "essentials"
I also believe that the Large house should be 4 lots, and the PA hall 6 lots, holding 400 items
I am saying this not from a point of view that i just want to horde lots of stuff, but i want to be able to collect rare items, and display them better in a "museum" like environment
ElBlufer
Sat Mar 06, 2004 5:44 pm
#2
200 items in a medium=yes
large house/PA hall lot changes=yes
rest of ideas=no
I hope that the I deas I agreed with actually come in game.
xwingkiller1
Sat Mar 06, 2004 5:48 pm
#3
you cannot have client side storage of items. if you did that, everyone would have a lightsaber that they can use thatdoes 50k max damage.
ZenDragonMLS
Sat Mar 06, 2004 6:33 pm
#5
Storing *anything* clientside in an on-line game is a huge gaping hole to drive things through.
TheMalle
Sun Mar 07, 2004 2:05 am
#6
Hehe, I remember a little mod to Half-Life called Master-Sword. It was a RPG and the saves were done client side. Funny how people can do 10000 more damage with a knife than my huge sword do 
Thornstar
Sun Mar 07, 2004 2:12 am
#7
I find the current storage limits fine. need more storage? get another house. cant get another house because u need harvesters? well thats the balance of the game, deal with it.
cleint side storage was put in the petition for a joke? Wow that player has 10 billion units of 1000 on every stat of metal/ore/chemical and gas.
Hunden
Sun Mar 07, 2004 3:30 am
#8
i would like to point out the sticky thread at the very top of this board called "About Petitions"
please go read this before thinking about posting petitions on this board.
hund
Whist34
Sun Mar 07, 2004 8:02 am
#9
I agree with everything except the clientside storage.
Denier Whist
Master Architect
aibo220
Sun Mar 07, 2004 2:51 pm
#10
The cost of maintenance plus lot consumption from a small to medium to large to PA doesn't add up.
The whole item limit needs to be revised.
Vorc
Tue Mar 09, 2004 1:58 am
#11
I would prefer that storage in houses be experimentable. Keep the current values as a base and allow them to be improved upon. This would actually provide a market for top quality houses.
Vorc, Master Architect, Kettemoor.
EnigmaBSc
Tue Mar 09, 2004 6:32 am
#12
Client-side storage is perfectly possible without opening the door for exploits. Imagine the following scenario: A new type of building as added, a warehouse, which uses 1 lot and can store 1250 items, without using more than the 75 database items that the developers have decided upon as a limit per lot. How would this work?
The warehouse contains 25 crates. Each crate can hold 50 items. Only one crate can be open at any one time. To store items the player opens a crate and drops the items they wish to store in to it. They then close the crate. At this point the server creates a serialized list of the items and sends it to the client. At the same this it computes a hash of these items and stores it in the database. Now the player might open another crate and store more items, e.t.c.
Later the player decides that they want some of the items from one of the crates. They go to the warehouse and look at a list of items and which crates the items are in (which can be determined by the client from the serialized lists). They then open the correct crate. At this point the client sends the serialized list of objects back to the server. The server re-calculates the hash on the list and compares it to the stored hash. If both hash values match then the server spawns the items from the list in the crate.
The main problems with this approach are:
1. Serialization/de-serialization of objects. This is a non-trivial task since each type of object may need to have its own serialization code. To reduce this problem, warehouses could be introduced in stages, where each stage is able to store a greater variety of items, initially starting with something simple, like resources (since all resources should be able to share the same serialization code).
2. Server processing time. The time to serialize/de-serialize may be significant. The hash should be be fairly quick to compute. Constantly removing items from and adding items to the database could fragment the database and lower performance.
2. The hashing function. This shouldn't be too difficult, but it is important to find a good hashing function to prevent exploits.
3. Storage is linked to the users machine. Anybody playing on two different machines would have to manually transfer the serialized item lists.
How does this prevent exploits? In order to open a crate, the stored hash must match the hash of the item list. Change the item list and its hash changes. Try and open the crate and the odds are you'll get a 'The crate is jammed shut' message, at which point you've lost the items in it, as well as the use of one of your crates. This makes attempts to exploit the system, which should be almost impossible anyway, costly. Since the hash is only stored and computed server side players never have a chance to see it and therefore to try and beat it off-line by running lists of objects to find lists with the same hash values. The hashing function could even be changed with each publish to increase security, although crates stored before that time should still be retrievable (requiring that all hashing functions are retained and that both a hash and a date are stored in the database).
Using a 64 bit hash and a perfect hashing function the chances of finding a pair of item lists with the same hash value are extremely small. If a million players each stored a million crates each and then one other player repeatedly stored a single crate of the same items and tried to retrieve it using the item list from one of the other players (in an attempt to convert the worthless items in his crate into hopefully valuable items) he would have a 0.000006% chance of success, and it would cost him a trillion crates and forty billion warehouses.
Does anybody have any comments? Anything I've missed? Anything that could be added? Is this an idea that people would like to see?
EnigmaBSc
The warehouse contains 25 crates. Each crate can hold 50 items. Only one crate can be open at any one time. To store items the player opens a crate and drops the items they wish to store in to it. They then close the crate. At this point the server creates a serialized list of the items and sends it to the client. At the same this it computes a hash of these items and stores it in the database. Now the player might open another crate and store more items, e.t.c.
Later the player decides that they want some of the items from one of the crates. They go to the warehouse and look at a list of items and which crates the items are in (which can be determined by the client from the serialized lists). They then open the correct crate. At this point the client sends the serialized list of objects back to the server. The server re-calculates the hash on the list and compares it to the stored hash. If both hash values match then the server spawns the items from the list in the crate.
The main problems with this approach are:
1. Serialization/de-serialization of objects. This is a non-trivial task since each type of object may need to have its own serialization code. To reduce this problem, warehouses could be introduced in stages, where each stage is able to store a greater variety of items, initially starting with something simple, like resources (since all resources should be able to share the same serialization code).
2. Server processing time. The time to serialize/de-serialize may be significant. The hash should be be fairly quick to compute. Constantly removing items from and adding items to the database could fragment the database and lower performance.
2. The hashing function. This shouldn't be too difficult, but it is important to find a good hashing function to prevent exploits.
3. Storage is linked to the users machine. Anybody playing on two different machines would have to manually transfer the serialized item lists.
How does this prevent exploits? In order to open a crate, the stored hash must match the hash of the item list. Change the item list and its hash changes. Try and open the crate and the odds are you'll get a 'The crate is jammed shut' message, at which point you've lost the items in it, as well as the use of one of your crates. This makes attempts to exploit the system, which should be almost impossible anyway, costly. Since the hash is only stored and computed server side players never have a chance to see it and therefore to try and beat it off-line by running lists of objects to find lists with the same hash values. The hashing function could even be changed with each publish to increase security, although crates stored before that time should still be retrievable (requiring that all hashing functions are retained and that both a hash and a date are stored in the database).
Using a 64 bit hash and a perfect hashing function the chances of finding a pair of item lists with the same hash value are extremely small. If a million players each stored a million crates each and then one other player repeatedly stored a single crate of the same items and tried to retrieve it using the item list from one of the other players (in an attempt to convert the worthless items in his crate into hopefully valuable items) he would have a 0.000006% chance of success, and it would cost him a trillion crates and forty billion warehouses.
Does anybody have any comments? Anything I've missed? Anything that could be added? Is this an idea that people would like to see?
EnigmaBSc
EnFERn0
Tue Mar 09, 2004 7:13 am
#13
Vorc wrote:
I would prefer that storage in houses be experimentable. Keep the current values as a base and allow them to be improved upon. This would actually provide a market for top quality houses.
Vorc, Master Architect, Kettemoor.
I agree with you on this one.
A storage vendor in house would alonebe too much.
Allow storage lockers in houses to increase room slightly.
But I would prefer Large houses and PA Hall have higher item capacity.
Page 1 of 2