Room is full?

[gfair]

Have you encountered problems that are, in your opinion, unrealistic with the "there is no room for that in here" response when trying to store items in a room?

I have encountere problems where storage compartments (i.e. footlocker, trunk, basket, chest) could easily accept dozens more items, but the room is full because there's too many items in other compartments.

Just curious to know if this is causing similar problems that you think are unrealistic.

[Cerebus]

The problem in the first place is that players have been using save rooms to store sometimes literally thousands of stones in items, when realistically there would be no room to squeeze in, let alone fit all the stuff in the first place.

Any changes which have suddenly limited the size of these rooms may have unfortunate temporary side effects, such as picking something up and not being able to put it back down. It shouldn't have been that full in the first place. As soon as the rooms are cleaned out and made more realistic, there will no longer be these weird quirks because the rooms wont be full in the first place.

Cerebus

[gfair]

Surely it would be easier to handle the issue by focussing on these uber-collectors, rather than making a change that affects everyone?  This new change works in complete contrast to the tendency of most players to store their gear in barracks/crafting halls/storage rooms.

Are there not significantly fewer collectors than general PCs?  Perhaps not, given the decision to make this change, but how will this be resolved? IC or OOC?

Also, the message that says the room is full implies that the room is full - perhaps a better wording, something like "all the storage compartments are used" would be more accurate?  Since a number of PCs can still fit in the room, and footlockers can be empty, clearly the room is not full.

Thanks.

[crymerci]

Well, I don't have one of the room types in question, so this doesn't affect me at present. But..while I can see that a number cap on items is the easiest way to go, it still seems like one could easily have 300+ items and not have a room be ICly crammed.

For example, in a guard barracks, ICly there are tons of people there, with lots of lockers. In reality, there's maybe 5 PCs each with a chest full of stuff, plus a few chests from players who've recently died, rarely log on, or whatnot. Plus some organizations use the barracks save room to store other things in: crafting raw materials, spare armor for recruits, communal items like waterskins and soap.

Second example: a noble or wealthy commoner has 2 wardrobes full of clothing, a jewelry box, a shoerack, and a chest. ICly obviously these items all would fit in a luxurious bedchamber, and with silks and jewels it is easy to go over 300 items without taking up that much space.

I don't mean to sound like I'm completely berating this change, just trying to show how one can justify such numbers of items. I would also like to respectfully suggest that this could have been maybe handled differently: perhaps having the PC clan leader instruct the peons to clean out the area, or at least give players notice so they can make reasonable efforts to sift through their items without having to worry about picking the wrong thing up and not being able to put it back down.

[Cerebus]

There are some false assumptions here. The limit isn't based on number but on weight. Part of the concern is about Ginka, however, which does not care about weight, but cares about number of objects that have to be loaded, saved, searched through, etc all the time. However, that's not to say that the IC concern isn't real. It's just something that has become more pressing recently. While this change was going underway, I've seen some CRAZY things. Like rooms with literally hundred of tenstones in weight, or scores of feathers in one chest.

These are my opinions and may not reflect the opinions of the staff as a whole, nor the individual staff members involved in making the change.

Cerebus

[Fedaykin]

One thing I would recommend clans with this particular problem take a look at is something we had going in Kadius, back in the day:

If you have a tremendous ammount of one item in particular (such as feathers for instance) and you're not going to be using it anytime soon, coordinate with your clan immortals to temporarily get rid of them.  You can junk what you don't need for now, logging the junking while you're doing it and coming up with total number at the end.  Then mail your clan immortals with the log and details of this now virtual supply of items.  Then, when you're nearing the end of the supplies you actually have in game, mail your clan immortal again and ask them to load some more of those items up and subtract them from the virtual total available.  This particularly helps cut down on the storage space actually used by the game for large numbers of low weight items while still allowing you to maintain your realistic supply of these items without the already mentioned negative side effects.  A win win situation.

[gfair]

Part of the concern is about Ginka, however, which does not care about weight, but cares about number of objects that have to be loaded, saved, searched through, etc all the time.

Ah, I see.  Ultimately, though, I think the technical needs do clash with high-volume areas with this limit.  What's the best way for large inventories to be handled, will this be something done by IMMs, or IC by PCs?

As a related idea, how about a junk command that doesn't have a public echo? That way you could junk unneeded items without having others comment from the IC perspective of wasted resources, disrespectful behaviour (breaking mugs in a bar, for example).

Wait... the Junk file says nothing about this, though I thought it was the one that said something to the effect of: "without a good IC reason, junking items is frowned upon". Is this still in the Arm literature, or gone?

[gfair]

If you have a tremendous ammount of one item in particular (such as feathers for instance) and you're not going to be using it anytime soon, coordinate with your clan immortals to temporarily get rid of them.  You can junk what you don't need for now, logging the junking while you're doing it and coming up with total number at the end.

This is a smart idea.  It has no weight, and may not even need be from the same object class, it could be a simple text string.  The question, then, becomes at what stage do you do this?  Perhaps this could be done as a new command for storing items "store <number> <item>"  = "you see <number> <item>s here", a proxy, and "unstore <item>" unstores those number of objects.  This is identical to sids and storing them in your bank.

[Angela Christine]

Surely it would be easier to handle the issue by focussing on these uber-collectors, rather than making a change that affects everyone?  This new change works in complete contrast to the tendency of most players to store their gear in barracks/crafting halls/storage rooms.

There don't have to be any excessive collectors for storerooms to become filled to the rafters.  I remember a time I was in a clan that had a number of lockers for the PCs.  They were all in use, and many were full of . . . junk; unused crafting supplies, excess gear, old clothes, spice pipes, all sorts of crap the PC owner hadn't used, but hadn't been willing to part with.  There were some new hires, so we were going through the chests trying to see what belonged to who, and if there were any lockers being "used" by dead PCs that could be cleaned out and assigned to the new employees.  An oldtimer in the clan was able to identify some of the more unique items, and after several RL days of investigation it turned out that all the equipment in all the chests belonged to dead PCs.  People had died, but no one cleaned out their locker after (probably because they weren't sure exactly what belonged to who) so this crap just piled up.  Some of it belonged to PCs that had died IC years before, but since we don't see the virtual dust there was no easy way to tell what was being used and what was just in perpetual storage.  No one felt like doing the OOC scut work, so no one did it.

Another time, with the same clan, I visited a secondary base.  As far as I could tell no PC had been living at the base for months.  I wandered into the storeroom and found it full of bags and chests of junk.  Well, not junk, but tools, crafting supplies, herbs, spare weapons and armor, hunting trophes and even food.  Bleh, food that has been in a store room for IC years.  Most of the stuff was potentially useful, some of it was even valuable, but since all the PCs living at the base had died there were litterally hundreds of items cloging the database that no one was using or planning to use.  So we went through it all.  Some of it we used, most of it we sold, and the rest we sorted stacked neatly into a few containers as a "seed" of materials for the next group that would inhabit the place.  Realistically the storeroom wouldn't be completely empty, so I left the stuff one would expect to find but cleared out the rest.


Sometimes we need a little motivation get things done.  Does the clan really need to keep 4 spare waterskins, 3 ropes, 37 travel cakes and 11 weapons in storage, just in case?  Not really.  If something doesn't get used for a few months, it makes more sense to converit it to coins (ie. sell it off and put the money in the clan bank account) and then buy a new rope, weapon or whatever when one is needed.  There are exceptions; very pricy items may be worth enough to hold onto, because if an item is worth more than 500 coins (like a tent) you are going to lose a lot of money selling and re-buying it.  Another exception is clan marked gear like uniforms, obviously this stuff shouldn't go into the shops to be bought by just anyone.  But for most generic gear it isn't worth holding onto.  Having the code show how full the room is by not letting you drop any more encourages us to have someone in the clan go through room and get rid of stuff that really has no reason to be stored.

AC

[Savak]

The most recent "default" change imposed upon the save rooms has gone into place because:

a) A number of rooms contain over a thousand items.  Each item is examined every time the game cycles ("ticks"), searching for programs, timers, triggers, etc. on EACH ITEM, EVERY TIME.  From a code/ginka point of view, the size of an item makes no difference when it comes to inducing lag, merely that there are a lot of them.

b) Save rooms have the largest continuous number of items in them and can be changed quickly, making them the most ready target to reduce clutter (and thus ginka-based lag).

c) Some rooms, even large warehouses, have been LOADED with tremendous numbers of items.  The majority of these items have then gone completely unused in-game.  If leaders are storing these things for VNPC's to utilize, there's no reason the items themselves cannot be made virtual.

So, yes, this concern and the changes resulting from it have been based on reducing lag, first and foremost.  Second to that is the simple fact that "clutter" is not well accounted for in the code -- most items have only a weight parameter, rather than also length & width parameters (as evidenced by people loading arrows & javelins into wristsheathes).

If you can demonstrate a "real" need to have 800 feathers, 700 stones, 500 dessicating flowers and 400 rotting pieces of food in a storage room and can convince your clan immortal of the same, then there are some options we can still exercise.  Meanwhile, please understand that we would rather see 10 stones junked and put in 10 extra scripts for ginka to chug over than leave those stones sitting in an obscure corner unused for the next 3 RL years, and we're not out to prevent you from storing your extra steel halfsword by your dresser.

-Savak

[crymerci]

... we're not out to prevent you from storing your extra steel halfsword by your dresser.

-Savak

As a side note, if anyone is having trouble finding a home for that extra steel halfsword, I would be happy to take it off your hands.  :twisted:

[The7DeadlyVenomz]

Yes...give me your home town and your Nenyuki apartment number. You will dead within the IC week.

Oooo.....steeeeel! :twisted:

[Bestatte]

Once more a question from someone who knows essentially nothing about Diku, but some amount about Lambda MOO:

Is there no way to code "virtual storage?" By virtual, I mean code-wise and not RP-wise. I mean a series of arrays. Where the array exists in the database, and the object only exists in the room when someone enters the room.

Example: A container stored in a footlocker, with the container holding several dozen items.

The container remains tucked neatly into the database, not "live" in the game itself, until someone opens the footlocker and takes the container out. Once it's out, the game loads it from the array it came from, and it now has the objects in it that the PC can utilize. When they put the container back into the footlocker, the contents of the container go back into the database and no longer exist in the game, until the next time it's pulled out.

It's the same as how PCs disappear from the game when you log off in a quit-safe room. They might no longer be in the game, but they still exist in the database, in "virtual" mode.

Can't this also be done with non-PC container objects? I only know it can be done with Lambda MOO and its derivitives, and it certainly can be done with any C++-derived code.

A brief description of this would be: out of sight, out of mind. Or in code terms, out of sight, out of game.

[Savak]

That's not a bad thought, but it's not built into Diku (or Armageddon).  Whether we can (or should) attempt something like it is a little over my head though, and sounds like it would either mean a lot of memory or a lot of disk read/writes.  Less cyclic updating of large numbers of "in-game" items, but possibly more checks made each time a person enters or leaves a room.  (I.e., it sounds nice but I don't know how much "real" resource saving it does.)

Hmm.  Maybe some of our coders can offer a more informed insight.

-Savak

[Bestatte]

Well basically...you'd make it work so that only certain items can be @virted.

Rocks of all sorts, herbs of all sorts, stones of all sorts. Things that are easily amassed by the dozens.

So you've got a container filled with two dozen stones of different types, and um.. a pair of purple stockings. The stockings would remain an "active" object in the container. The stones would all go into the array of "stone objects."

Walking into the room was misleading.. I was kinda half thinking at the same time about piles of stuff sitting on the floor. I meant when a PC tries to interact with a container that contains objects, whether that be a room or only certain types of backpacks, herb satchels, or even stealing the contents of someone else's belt-pack.

The only time a system check would be needed is if someone actively attempts to interact with the container. So you could walk around all day long wearing your sack-o-stones..and it would remain "virtual" until you try to put something in, or get something out of it.

Putting something in it would place the object into the database, even though it would be "listed" as contents in the container. Kinda like, the container stores only the NAME of the object, but not the object itself. The name would be a place holder, so that when you type "get stone pack" the placeholder checks the "stone_object array" for the stone that matches the placeholder's name, and procures the object.

Placeholders, arrays, pointers.. very basic stuff for C++ but probably some heavy coding required to get it started in Diku. But once it's done, it would be a HUGE load off the game's resources. The LambdaMoo-based game I know of uses this as a matter of course, saves the entire game automatically every 15 minutes, and has -no- lag. (Unless there's something wrong at the moment, such as major bugs or internet issues)

[creeper386]

The only time a system check would be needed is if someone actively attempts to interact with the container. So you could walk around all day long wearing your sack-o-stones..and it would remain "virtual" until you try to put something in, or get something out of it.

This would require a disk read for every look... A read for every get/put, a write for every put... Which might add up to more over all. Although it might work for store rooms, and such. So the code doesn't have to go through every small item and the containers aren't checked all the time and only so often. And text files ussually don't take up any amount of space at all.

Maybe what could be done... is some code to group things together. Like say there are 20 blue stones. 19 of the stones are normal but one is magical. The code groups the 19 stones together because they are the same, and each tick it checks the 19 stones all together and then the other stone seperately. I don't know how easy it would be to code but it'd certainly cut down on all the checks.


Creeper

[j0ram]

Hmm.. skimmed through this thread, so not sure if I'm repeating what someone else said...

It sounds like the way saverooms and player object files are saved is that each individual object is entered, even if there are multiples of the same vnum. If this is the case, have you considered changing the code to stack like vnums on the saveroom / pfile object files? So if you have 500 of the same rocks in a chest, it stacks them, so the files don't have 500 entries for the rocks, but instead one entry that denotes there being 500 like vnums.

[Lazloth]

This would require a disk read for every look... A read for every get/put, a write for every put... Which might add up to more over all. Although it might work for store rooms, and such. So the code doesn't have to go through every small item and the containers aren't checked all the time and only so often. And text files ussually don't take up any amount of space at all.

I don't think you're understanding what's been suggested.
The idea is to load the objects when first queried; they aren't flushed from memory immediately afterwards.

[Bestatte]

Kinda correct Lazloth. The way I see it with a C++ pseudo-pseudo-kinda thing...

Player's satchel contains 50 stones of all shapes and sizes.

Code identifies all 50 as "stone objects."

Player closes satchel, OR player places satchel in another container, such as a wardrobe, chest, or backpack.

Code places "all stone objects contained inside satchel #548" into the "stone object array" within the database. Result: the game no longer contains any of the 50 stone objects, though they are safely tucked away in the database. In the meantime, a "placeholder" called "50 stones of various sizes and colors" is placed in the container, so anyone looking within will see:

50 stones of various sizes and colors.

Player opens satchel or removes non-openable satchel from his other container..

or another player steals it

or another player removes it or whatever.

Player types "get stone satchel"

Satchel object has that placeholder, which the game code recognizes as a request to search the database. The code immediately reloads the satchel with the actual stone objects, and pulls out whichever one the player asked for (assuming it's there). Error message returned if nul.

Satchel is closed or put back away, and the stone objects return to their array, with the appropriate "49 stone objects" in place.

[ashyom]

Here's my simplified point of view (disclaimer: Not necessarily wholly the Staff's view).

Individuals and Their Homes
I can see why this is a problem for some of you, code-wise.  We are taking steps to adjust the larger rooms - like warehouses, or storage rooms.  However, from IC point of view, most of the apartments that players live in are quite small.  8x8 - 12x12 is a fair estimate on how large most apartment-rooms for commoners are.  I honestly don't think you could find room for a bed, a table, and 1000 of whatever items you're squirreling away (unless they were feathers, which would strike me as odd).

We will adjust the larger rooms as we go through them.  This is a new "discovery" for the staff, and we haven't had the time to go search all of the 25+ thousand rooms to find that one room that should be bigger and alter its size.  The staff is very much aware that not all rooms are same, that some - particularly those owned by the rich and famous - would probably have more space.  In the next few weeks, the rooms that we think should be more roomy; the staff will adjust those when we have the time.

Simply put.  Be patient!

Clan Rooms
Next.  I don't see the need for "stacking the items", or however you would call it.  Most things are bulky, they take up space, and the weight would of course have to be factored in.  Here's a scenario that keeps playing out in my head.  A merchant lugs around a "stacked, 20-items" stones that weighs 50 pounds in a bag.  Would an average merchant be lugging around 50 pounds of stones?  Would a thief really want to grab 50 pounds of stones in one attempt?  Not likely and Not if he's sane.  Am I shooting down the idea?  Yes and no.  Read on.

However, the notion of figuring out a way to "stack and/or store" supplies virtually until there is a need for them, and then pulling them out of the files, has merit.  That is basically what the clan imms are manually doing right now for the folks in their clans, and having this set up semi-automatically would be one less thing to depend on us for.

For those of you who do have access to a clan's storeroom/warehouse/ crafter hall.   Until we decide whether this is will go in or not, the clan imms will compensate for the loss of "real" supplies by recording whatever is converted to virtual supplies.  So, you aren't truly losing these goodies.

Again.  Be patient!
Ashyom

[Impska]

I've recently done the cleaning in a storage room for crafters for my clan. Every chest was emptied and the contents junked except for about 10 items and a few gems. But I still can't drop things in the room. I've noticed that I haven't had problems with shifting items anymore, which I had before, so I assume I have made -some- dent in the problem.

So the question here is: Have I really helped much at all? Is it the chests in the room that are taking up the room space, or do the contents of the chests also add to that? If so, why are these 25-odd small items impacting the room so badly?

I've wondered if I should move a chest or two to a different location, if that would help, but to be honest, I'm afraid to move them in case they don't go back into the room (or any other room) afterwards, or it doesn't make a difference to whether or not I can drop something.

Are all rooms set equally? It seems a bit unfair to mark a huge barracks or crafting hall the same as an office.

[creeper386]

Ah, yeah. I see what your saying there. But still most the time I open and close my backpack alot too... Hehe.

I think some sort of code that checks all of one object together would probably be better though. Instead of 50 checks on fifty little black feathers, it makes one check because it's all the same. If anything special is on them it can always be handled to do fifty times, but you took out 49 operations right there, right?

Basically stacking codewise, not IC wise. Think some limits on how much a room can hold is a good idea, myself. Liked to see more limits on how many (n)PCs can fit into a room and such. Like for the smaller rooms and such. Know it's possible.

Creeper who doesn't know anything so shh!

[Kalden]

I've noticed that I can only put one thing in my locker, be it a slender length of bone, hide, or a little feather.

[Cerebus]

There have been additional changes made since the orininal limitations were put in. Feedback I've seen commonly complained that it was unrealistic that containers such as chests cannot hold any more because the room is full, even if the container is empty. So more changes were made. Now containers take up space in the room dependant on how much they can hold, not how much they DO hold.

What does this mean, and why is it important?

It means that if room may be full if you have 10 empty chests in it, however, you should now be able to put things in the chest, even though the room is full. It is important, because it means the rooms will likely have less on the floor, because containers will now take up most of the space. If all you have is containers in the room and you still can't drop anything, that means either you have too many containers, or the room is set too small. I have gone through several Salarr rooms and both removed containers and adjusted the size of the room. Now there is room to fit a few things on the ground, but not many. That's how I like it. I don't want to enter a room and see a scroll that's five pages long. However, there are still 5-10 containers in those rooms, so you can still store a lot of stuff in the containers. Unfortunately, a lot of these tweaks have to be done manually. If you have a clan imm, you should probably email them with your problems. If you have public housing, then you might want to typo your problem or email mud@armageddon.org, and If you CC me, I might be able to fix it.

One last thing to note. Bags and sacks are containers, and therefore take up space  IN A ROOM according to their capacity. You will likely want to store bags and packs in other containers, because they take up less room that way, unless they are full. This is not a perfect solution, but it is the most practical we have come across, to date.

Cerebus

[creeper386]

Although it'd take going through containers and setting them maybe another flag for soft and hard containers. Chests and stuff would take up as much space as they CAN hold, while bags and packs take up as much as they are currently holding? Be time consuming but pretty nice thing even if it's not noticed too much.

Creeper

[gfair]

Are all these items to be removed from the room going to be put in some mega-room somewhere in the game and available on a first-come, first serve basis?  :lol:

The revisions have made a noticeable difference.  I think much of this issue comes down to how we all perceive space and room size, what with whether or not we can tuck things in a small nook in a cot, though it lists to players as "on the floor", and whatnot.  Since rooms are 3D, there's a remarkable amount of space available in a square room if you're smart about it, so at first I thought the change was a bit extreme, seeing as how my own survey of several rooms revealed plenty of open space, but a full room.  Glad to see the feedback has been incorporated.

One last question though - initially, I found out that the quota was based on cumulative weight. Did that exempt the weight of the containers and whatnot?  And if so, does it still?  Why? Just curious to know, thanks.

[Cerebus]

One last question though - initially, I found out that the quota was based on cumulative weight. Did that exempt the weight of the containers and whatnot?  And if so, does it still?  Why? Just curious to know, thanks.

I had trouble following the wording of this question, but I will try to answer what I think is reasonable to share. Previously, if you had a chest, the weight of the chest and contents would be counted, and the room would be checked before you could add weight to the chest. If it was over the limit, you couldn't add anything to the chest. This is what cased the effect where you could remove something from a chest and then not have enough room to put it back.

Based on feedback, code was added to change this. Chests and other containers now count against the room according to the amount they can hold. However, anything put in the chest does not count. So if you have a chest that can hold 50 stones, even empty it will take up 50 stones in weight in the room. Full, it still takes up only 50 stones in weight in the room.

The numerous virtual spots in the room to put things are.. well.. virtual. You can look at the weight limit as virtual too. A 500 stone limit in a room doesn't necessarily mean in the middle of the floor.

As for hard and soft flags for containers, that was briefly considered and set aside. Adding the code would be cumbersome and just add to the complexity of object structures without any real significant gain. We aren't going to be able to please everyone, but this is what was felt as the best possible compromise of efficiency and realism, so far.

Cerebus

[gfair]

We aren't going to be able to please everyone, but this is what was felt as the best possible compromise of efficiency and realism, so far.

I think it's an acceptable compromise to keep, though the side-effects may be interesting, or annoying, if they work out as one could guess.