New houssing type and npc driven warehouses

[Hellblazer]

We've all seen the player/gm drive suggesting player management of their inventory. I agree, but at one point there is so much some one can do if they have time constraint and or storage constraint. Should we simply say to someone who can't store things not to enjoy crafting if he can't craft everything at once, because he could potentially create lag? I don't think that would be fair to any one so here is my suggestion to help in that regard too, but without taking away the responsibility of a player to manage their inventories.
 
 1- Multiple houses in a single Area with enough spacing to prevent hearing talk channel chatter
 
 Presently most houses have a certain number of tiles they occupy while there is a much bigger size of area that is available. Yes it's longer to load on the player side, but at the same time putting more houses into one area, would solve the problem of Area numbers.
 
 2- NPC driven warehouses, one per major city, with multiple single locked door rooms that can be rented out directly from a npc, that would hand out one key. Where someone can place their crates to store their stuff. Since it's npc driven, if a player is found not to be playing anymore and the space is needed, the team would be free to take the stuff away.

[Hellblazer]

There are other problems, Hellblazer. I don't know the intricacies of the housing system, but I can make a guess at it.

Given that, at the moment, houses are unique areas, I'm guessing that the area tag is the primary index of the database that records the location, orientation, and contents of all housing placeables. By putting more than one house in an area, you would need to create an entirely new database which indexes by something else (owner, perhaps, or an id attached to a given key). You would also have to migrate all the existing information, or (more likely, because all the locations are going to change relative to the area size) require that everyone clear everything out of every house. (!!!)

Now, on top of that, any script that employs the existing database would have to be altered as well. Persistent chests, the deeds, the house-content-loading script, the key scripts, the door scripts, and, likely, the real-estate scripts.

Serving larger areas also provides a drag on server resources - one of the principal guides to PW development says, multiple times, that larger areas cause massive lag - so avoid them. Areas with 800+ dynamic furniture objects (four or more houses in the same area with the maximum number of placeables) would be nightmarish.

So no, it's not just transitions, Hellblazer.  This would be a major overhaul of an integral system

Not to mention, how would you make a single houses floorplan larger if the owner decided to pay for a renovation and add an additional 2 or 4 tiles to their floorplan and there simply was no room to do so because all the other houses floorplans in the same are were already squished up next to it?

But really, this has far digressed from the intention of this thread, which was to inform about changes with the most recent patches.

yes I remember reading those when I was making the areas, but those were mainly for adventuring areas if I remember. Houses are not use to the extend that they would create such a massive lag even less for the loading time now that they have spread it over 40 seconds.. But yeah for the database thing I knew i was missing something, that is a very good point. for the community housing project. Although it doesn't count for the npc warehouses, as it would simply use what is already in game beside the npc script to hand out the key. And my guess is that persistent chest are saved to owners already, because you can set them in any houses/guild/inn interior areas by anyone, and they can be locked or unlocked only by the one placing them. So that wouldn't change.

Nehet, the bigger houses have roughly a 9 by 9 tile set at the moment if I remember. The larger areas are 32 by 32 if I remember correctly that still leaves space to have them made bigger. BUt 32 by 32 is huge really huge... I madea desert out of it once, massive... too big to adventure in. if you take a 9 by 9 house leave 5 tyles sent in between them, and put the other one that is still 24 by 24. Big but not overly.

moving these here so not to derail the thread started by orth anymore.

I'm not sure how the system handles the void in areas, the space that has nothing in it, but my guess is that it would not create that much lag. There wouldn't be any spawn, the exterior of the houses wouldn't be walkable, so no need to put anything in the between houses space.

The problem with making uge maps, is not really the size of the map by it self, but more what you will put in it, spawns etc. If there is nothing but the houses and the placeables, then lag shouldn't be more than it is now.

[Dorganath]

Actually, darkstorme is very close on his assessment, regarding the intricacies and pitfalls of combining housing areas. Close enough, probably, to say, "Yep, that's right" without much need for further clarifying minor points.

It's worth saying that we had actually intended to have a "apartment" system where a character could go and rent a room or two within a larger structure.  It was pretty well planned-out, but unfortunately the guy who we had tasked to work on the project up and vanished in a blink with no word, and since we lack the "full time" resources to tackle something of this scale, it's not likely to happen.

Keep in mind, this is something that would have happened in addition to the existing housing system, not to replace it.

Getting back to other issues... As darkstorme suggested, aggregating housing into single, larger areas is very much a non-trivial effort, causing far more problems than it solves.  In truth, the only issue it really solves is the limit that Bioware has in-place for the number of object files a module contains, which includes areas, scripts, conversations and everything in the palette.  However, we are well under that size right now, so it's not a concern.

The real issue with area bloat is what it does to contribute to overall module size.  Our modules are now over 100MB each.  A single large area is also less efficient, size-wise, than a collection of smaller areas.  If you consider that most non-remodeled housing areas are on a 4x6 grid (some with blank tiles), with maximal arrangement (which I don't think is possible taking doors into account) in a 24x24 are would be room for 24 housing areas.  As each house could have up to 200 dynamic placeables,  that's a potential of 4800 placeables in one area.  While true, a PC would never see all of them, but the game doesn't know that.  

Now granted, we can't have that case because we have to leave blank tiles for proper handling of exterior doors, space allowances for remodeling, etc.  We'd be lucky to get 12 house areas in a 24x24 area, and even that is probably too big for most PW design guidelines, considering that  most of our areas aren't larger than 12x12 (except in some special cases), so we're realistically at 6 houses per area, but that's still a potential of 1200 placeables that could potentially be active any time someone is in one of those houses, whether they're seen or not.

That's a lot, and more taxing on the server, client and network traffic than discrete areas doing the same thing.

[Hellblazer]

IF you want Dorg, I can make the planning for the ware house ( i was not referring to livable areas but really for storage kind of a storage space rental unit thing you see in big cities) I could then send you the erf, that you could implant anywhere you wished it?

Now that part would really be a scripting issue. But would there be a way to have specific crates to load only if a specific door is open? Let say you got the unit 1 door opening, only the placeable in that unit would load?

I'm thinking here that one unit would have a special tag that would tell any placeable that is set in that unit to load only if that key is used. Since the doors would be locked, the chests wouldn't have to be, there for they could be provided with the room itself.

Also to avoid one single player owning 10 of those units, in the same city, the npc rental agent, would only give one key to any Character, A bit like the ox trader does, but instead that would only apply per city, meaning one char could have an other one in an other city. This way it would also serve as a database and storage control. I can easily fit 28 crates in a room like the one in Krandor (the small one beside the front doors) but that would be too much for those units. I was thinking maybe setting a max of 10 crates per unit, each warehouses having 20 units.

But then again if we limit the numbers of placeable to 200, it should pause any problems to have them all load as usual.

[Chongo]

I think you're missing what Dorg explained Hellblazer.  I'm not going to assume I can speak for him - but I'd recommend reading what he wrote again.



Warehouses are, in my opinion, one of the worst uses of server space possible.  I've erased over 100 areas on Layonara to make space.  And whenever I look at housing, which I'm guessing in 90% of the instances is used purely for collection/ storage - I cringe at the fact that I had to clean areas that were accessible to all, and offered a possibility of roleplay (granted - they were cleaned from the module for good reason - just saying).  And to be fair, houses have a small footprint.  But the idea of warehouses makes me cringe.

I know you're trying to come up with solutions to Orth's request for personal inventories - but warehouses, in spirit, are pretty much the problem's first cousin.

There's a lot to say about housing, crafting, our economy, etc... everything that I usually like to place the blame of excess and misuse on.  But it's really complex at this point after so many years of doing it that way.  And making an effective change simply isn't simple.

In all of this, I can promise one thing - what we're going to be left with is the same old answer: Try to be aware of your footprint, and be vigilant in keeping it clean.

[Dorganath]

Warehouses would not an area build issue but a systems/scripting/database issue.

[Hellblazer]

Maybe you could better explain the database issue. Right now we have people renting rooms, although there is very little that advertise or are there to provide the rooms anymore, where people can set up their crates in them to use. The ware house would basically be the same thing, but with no PC owners.

I understand why it wouldn't work for community housing, but those that rent houses and the renters that already put crates, haven't created a different database to do that no?

There is a script that already exist to dispense keys, all it need to is mode it to hand only one persistent key per chars for that specific warehouse. And to make the key only open one specific door. And that script you already did it in the single player module for the Inns. So not needed to redo the script here.

The chest script wouldn't have to be change since each unit door would be locked, which in term already exist in game, with inns lockable doors.

So really it's a database issue more than scripting, but I don't see how it would be since we still can put chest in houses that don't belongs to us and use them, without having to create a different database.

And yes I know its easier just to ask the player to carry less, but that hasn't work as of yet either.

[Dorganath]

The database is probably the least of the three issues.  Yes, all these scripted systems already exist, but they'd have to be modified (or nearly duplicated) to support a different style of "housing".  Mechanically speaking, there's not much (or any) difference between a house and a warehouse, but most of the housing system's coding is highly dependent on passing through a door transition from one area to the next, or working within a specially-tagged area.  

Rentable apartments and warehouses, while similar, would require a non-trivial shift in logic.  Rather than 200 placeables per area, we need to divide up such a multi-unit dwelling/storage facility into sub-zones and have logic that a) limits furniture to be placed within the triggers only and b) allows a lower number per sub-zone.  Rather than having an exterior door  and associated transition doing specialized tasks linked by area tags, we would have to adapt systems to an arbitrary door with no transition linked to some other system of identification for objects and the like.

And yes I know its easier just to ask the player to carry less, but that hasn't work as of yet either.

And here's the thing...none of these proposed systems will alleviate that.  There's a fundamental player behavior that involves keeping many things directly in the character's inventory that is the main issue.  It's not, unfortunately, an issue of want for available storage, as I know there are plenty of people who have access to sufficient storage who have been guilty of a pack-rat sort of behavior from time to time, my own primary character included.

There's a saying that goes something like: "Clutter expands to fill the available space."

The solution to that is to not clutter.

[Hellblazer]

I better see what you meant now. yes it would be a bit of a tweak to do.

But the question is. What if we don't need that logic? If the only person that can use a key is set to the person that buys it and is none transferable. Then we can have the storage set in the building it self, not by the players. A bit like bank chest.

This way we can control the amount of space one unit can have and respect the 200 limit of the area. Like i was saying 20 unit with 10 chest each = 200. They don't have to be placed by the player and they would be secured by a locked door. The key is to tag the keys not to be transferable.

So with this logic,
1- All the systems that is already in game are reused.

2- No need of modifying the "housing" system. (so no logic and database changes)

3- The Inn lock door system script of the Single player module can be reused. But a tag is set on the keys not to be transferable but to also be persistent.

4- The chest system is reused without any mods to it. But that is set in the module and not by the player. Although you could use the bank chest persistent storage script but with the tweak that it can not be accessible by any other chests, nor the bank chests themselves. I'm choosing this one as it is already used on chests that were setup at the module level and not by a player. But if the regular persistent chest script can be use, then no need to modify any script. (again no logic and database changes) Also with the new goodies about the chest content being showed on the info card, the player can take pics of the info card read out. So if there is a problem with the persistent storage losing items, it would be easy to see what was lost. And even if the items are not saved under the name of the one that lost them, being that the key of the unit is tagged to that character, it would be easy to see if the item was in fact in the character unit only by adding the number of the unit in the chests tags. An example would be chest 1 of unit 1 Hempstead. chest 2 of unit 1 Hempstead.

5- A script for a npc to dispense the keys is created. It would have to check which room are still available to rent and would hand out one key per character that is renting the room. Or even better and easier. The player would be able to see which rooms are available, like when you buy a house from the real estate agents. So again just taking a script that already exist and configuring it to work with this. I think here, It's simply setting the unit numbers as house numbers. The same script would then be able to see what is available without having a major overhaul.

6- A timer is set on the key so that when the equivalence of a RL month time has passed, and you use the door to your unit, it reminds you you need to pay the rent to the npc. The door doesn't open until you pay the rent.

7- The placing of placeable is disallowed in the warehouse by characters.

8- Only one unit per city (if there is multiple warehouse set up in different cities) can be rented by the same character. This prevents one character of owning multiple units of the same warehouse and contribute to the shortage of space.

This way you don't change any pre-existing logic, and you only have to make two script and mod two of them.

We can over complicate things or we can duplicate what we already have in game without having to change the existing settings. Placeable that are set in the module itself can still be used, if I remember correctly, and you can apply the persistent storage script to them. So this way you don't have to rethink the logic of the housing system. Even if the crates load at the opening of the front door. It is still only 200 crates, spaced within the 40 second load. And as it was said previously, they only load once. Which is in no way different than a regular house filled with 200 placeables, since the content of a crate only load when that crate is open.

And here's the thing...none of these proposed systems will alleviate that. There's a fundamental player behavior that involves keeping many things directly in the character's inventory that is the main issue. It's not, unfortunately, an issue of want for available storage, as I know there are plenty of people who have access to sufficient storage who have been guilty of a pack-rat sort of behavior from time to time, my own primary character included.

There's a saying that goes something like: "Clutter expands to fill the available space."

The solution to that is to not clutter.

I agree with all that you said, but unfortunately we can not rely on people to always do what is right.

On the other hand we can provide those that do the right thing, the tools to keep on doing the right thing. But also those lower levels that can't afford houses, that are learning crafts, would now be able to store their things without having to drag them around on a constant basis. Not only craftable materials but other personal stuff too.

[Hellblazer]

And just in case it was misunderstood, this is One building with 20 units in it, in one area. Not 20 small buildings in one area.

I made a quick calculation of the tiles and this is what I came up with.

A corridor would be 1 tile wide by the number of unit set on each side of it, long. A room would be i tile long by 2 tiles wide.

there is two ways this can be made.

Model 1- A building where the units are set on the length of a single corridor. 10 unites on each side of the corridor. A front room with the NPC and his desk.

So the total area size would be 5 tiles by 12 tiles.

-----------------------------------------------------------------

Model 2- A building with two floors in the same area, just a transition at the end of the corridor with stairs up. (like some of the houses of Leringard)

you got on the first floor the front desk then 5 units on each side of the corridor. On the second floor, simply 5 units on each side of the corridor, with no front desk room.

So the total area size would be 11 tiles wide, by 7 tiles long.


The front desk room could be simply 2 tiles long by two tiles wide it wouldn't change anything to the math I did as I included them in it.

[darkstorme]

While I appreciate what you're trying for here, Hellblazer, I can see a number of major issues with this system.

First, from the sounds of it you're proposing that these rental storage units be placed in multiple cities - and that they be double-decker.  So that's dozens of areas, right there, regardless of their size.  Next, you're proposing that each of these areas have an outrageous number of usable placeable items - a major lag issue, despite the Team's heroic efforts with regards to placeable loading!

Now, making these things static rather than dynamic doesn't help much, because this is drastically different from the way the bank chests work.  The contents are tied to the tag of the persistent chest, rather than to (for example) a unique character ID.  So what you have there is a strange amalgam of the housing placeable system and some other persistent storage - definitely a new system.

The Inn lock door system script of the Single player module can be reused. But a tag is set on the keys not to be transferable but to also be persistent.

I don't know if you've done any PW scripting, but the techniques used in single-player modules are not, as a rule, easily converted for use in a PW.  Persistence is one of those particularly tricky ones that really wouldn't have come about if it weren't for Avlis and NWNX.  It's doable, but it's nowhere near as simple as you seem to think it would be.

Point four sounds like additional administration for a system that doesn't seem strictly necessary in the first place.

Point five... is, at the very least, simplistic, I think.  Bear in mind, the "houses available" script isn't just a list of houses available, but rather a part of a system that attaches a player name to a house.  So "simply assigning unit names as house names" almost certainly won't work - I can't imagine that the database is configured in such a way that the number of nulls required would work.

Point six: If I agreed that this is a system that should be implemented (I don't), I would say that to facilitate this process, rent would be drawn from the character's bank account every two RL weeks (30 IG weeks.)  In the event that the account is overdrawn, all contents of the room are pawned to pay off the debt, and the room is made available.  Again, however, I don't think this is a necessary system.

In your original point eight (and still implied) was the caveat that one character could rent multiple units, provided they were in different cities.  This totally defeats the purpose of providing a place to put things for those who can't afford or can't find housing.

Again, if I supported this system, I would add a point #9: no character who owns a house can rent a storage area.  But that, sadly, is insufficient.  Take, for example (and not to pick on you, Hellblazer), the Angels.  You have a group of people who use a large house/guildhall for storage and living space.  But only one person owns the house.  The others would be free to rent these storage units.  And with only 20 spaces available, you can bet that they'd be snapped up more or less instantly.

So in order to keep some available, the pricing would have to be commensurate with the desirability of 350 slots of storage - say 5000-8000 True/2weeks RL.  And right there, you've priced it clean out of the range of the types of people who can't reasonably afford a house... but it doesn't matter, because if you don't do that, they still won't be able to use it, because it will all be occupied!

As Dorg said, the tendency is for clutter to fill all available space.  By making more space available, you're not alleviating the problem; you're enabling it.

[Hellblazer]

First, from the sounds of it you're proposing that these rental storage units be placed in multiple cities - and that they be double-decker. So that's dozens of areas, right there, regardless of their size. Next, you're proposing that each of these areas have an outrageous number of usable placeable items - a major lag issue, despite the Team's heroic efforts with regards to placeable loading!

You missed my point there Darkstorm sorry. I am talking of 2 floors in one area. Like the houses in Leringard are made check 127. that house has 2 floors in 1 area, that is what I am talking about. Even if you put one warehouse in the 5 major cities across west and central (see below*) that is still only 5 new areas.

It would be exactly the same amount of placeable for the entire warehouse of that city, that is already allowed for the houses. So no major lag there, even less since they have overlaps the loading time on a 40 seconds delay.

Now, making these things static rather than dynamic doesn't help much, because this is drastically different from the way the bank chests work. The contents are tied to the tag of the persistent chest, rather than to (for example) a unique character ID. So what you have there is a strange amalgam of the housing placeable system and some other persistent storage - definitely a new system.

It's actually not a new system at all. The bank chest were place at the area level (IE not placed by a character), probably when the area was being made. Then the bank persistent storage scrip was applied to it. This would be exactly the same thing. With the only difference that it would be a copy of the bank persistent storage script revised, so that no items that was placed in a chest, would be accessible anywhere else, but by that chest.

The tags I mention is only to be able to see through the database, what chest and in which location, the items was stored into. And I only propose the bank system because I didn't know if the regular script for persistent storage (see the player placed chests) would be able to work with a static chest.

Point four sounds like additional administration for a system that doesn't seem strictly necessary in the first place.

How would it be? when there is an item that is lost by the bank system or the chest system, you already ask for a picture or any means to prove that you had the items. The fact that you now can examine a chest to see the content makes it easier to take a picture of all the content that is in there. It will actually help you guys for that.

But I realize this can only be made with the regular persistent chest script and not with the bank one. Which goes back to my question. Does the regular chest script work with static chests?

Point five... is, at the very least, simplistic, I think. Bear in mind, the "houses available" script isn't just a list of houses available, but rather a part of a system that attaches a player name to a house. So "simply assigning unit names as house names" almost certainly won't work - I can't imagine that the database is configured in such a way that the number of nulls required would work.

I might have explained this in the wrong way. But what I meant is that you would see the same conversation and listing like what you see in the real estate.

"here are the units that are still available" Unit 1, unit 6, unit 10, unit 17, unit 20. Instead of seeing house numbers you would see unit numbers.

Now you have to remember that I am not saying that the unit is attached to the player name, because then we have to rethink the logistic of how the database will save the locations and items in it, how it will load it. Like Dorganath said previously. No the unit are part of the warehouse, and what denotes which unit belongs to someone, is the key of the unit door, that's all. All the items are saved by chest id.

For practicability issue. The script as I understands it, checks the database to see which house is tagged to a player name, then puts the houses that are not owned into a list that the player can view. Now what the copied and revised script would check the database for which unit door key is tagged to a character id, and list those that are not. It's basically the same procedure with two different variables. Instead of looking for houses that are tagged to a character id, it would check for unit keys.

Point six: If I agreed that this is a system that should be implemented (I don't), I would say that to facilitate this process, rent would be drawn from the character's bank account every two RL weeks (30 IG weeks.) In the event that the account is overdrawn, all contents of the room are pawned to pay off the debt, and the room is made available. Again, however, I don't think this is a necessary system.

That point was purely for rp reason and to keep the gold drain going.

In your original point eight (and still implied) was the caveat that one character could rent multiple units, provided they were in different cities. This totally defeats the purpose of providing a place to put things for those who can't afford or can't find housing.

After rethinking about it, I agree with you that only one unit should be available per character.

Again, if I supported this system, I would add a point #9: no character who owns a house can rent a storage area. But that, sadly, is insufficient. Take, for example (and not to pick on you, Hellblazer), the Angels. You have a group of people who use a large house/guildhall for storage and living space. But only one person owns the house. The others would be free to rent these storage units. And with only 20 spaces available, you can bet that they'd be snapped up more or less instantly.

So in order to keep some available, the pricing would have to be commensurate with the desirability of 350 slots of storage - say 5000-8000 True/2weeks RL. And right there, you've priced it clean out of the range of the types of people who can't reasonably afford a house... but it doesn't matter, because if you don't do that, they still won't be able to use it, because it will all be occupied!

I totally agree with you there for character that have houses should not posses a storage unit in a warehouse.

But I don't with how you perceive the guild working. In the Angels for example, only two person were staying at the guild hall, because they did not have houses. Having all the member stay there would have been completely impractical as we would have been fighting for space for our cnr, which some times we were already having problems with, that we had to use the house of the permed Mercas as a storage depot.

*Also you forget one thing. If you put one warehouse in the major cities of west and central: Hempstead, Vehl, Mariners hold, Prantz and Dalathar, for example. Then you have 100 units that are available. We don't even have that many chars that are plaid consistently. So there for you would have more than enough. And even then even if you kept the prices at 2000 per RL month. Then it is still attainable by the starting players.

As Dorg said, the tendency is for clutter to fill all available space. By making more space available, you're not alleviating the problem; you're enabling it.

Like I said, you can not rely on people to always do the right thing. But you can help those that do, to keep on doing the right thing. This is not aimed for those that don't want to change their ways. It's aimed for those that are already trying, and the new players that will come on the server.